Verify a sending domain
Add a sending domain before you send email to external recipients. Eza requires SPF, DKIM and DMARC verification.
Eza recommends a dedicated sending subdomain such as mail.yourapp.co.ke. A subdomain protects the reputation of your main domain and avoids changing an SPF record already used by Google Workspace, cPanel or another mail provider.
- Beta
- Sending API
- SMTP relay
DNS records
Add the DNS records
The dashboard shows the exact records for each domain. For mail.yourapp.co.ke they look like this:
| Record | Host | Value |
|---|---|---|
| DKIM TXT | eza._domainkey.mail.yourapp.co.ke | Eza-provided 2048-bit RSA public key |
| SPF TXT | send.mail.yourapp.co.ke | v=spf1 include:spf.eza.co.ke ~all |
| MX | send.mail.yourapp.co.ke | Eza-provided mail exchanger |
| DMARC TXT | _dmarc.mail.yourapp.co.ke | v=DMARC1; p=none; ... |
Pending engineering: the exact record hosts must come from the implemented verification system. Test these samples before publishing.
- DKIM uses a 2048-bit RSA key for each domain, with selector
eza._domainkey. - SPF uses
include:spf.eza.co.keon a bounce subdomain. That subdomain also receives an MX record. - DMARC must exist with at least
p=none.
Before verification
Sending before verification
Until a domain is verified, email can only be sent to members of the sending Organisation.
Ownership
Domain ownership
- A root domain and its subdomains are verified independently.
- A sending domain belongs to one Organisation at a time.
- Another Organisation can claim a domain by adding a new TXT record. The original Organisation is emailed and loses the domain after a successful claim.
- When a domain moves to another Organisation, it must be verified again with new DNS records. Its suppression list stays with the original Organisation.
- When Organisation ownership transfers, sending domains, API keys and suppressions stay with the Organisation.
Transactional email