Email DNS: SPF, DKIM and DMARC

Mail providers decide whether to trust your email partly from DNS records. Without them, messages land in spam or are rejected, and scammers can impersonate your domain.

Receiving: MX records

MX records list the servers that receive mail for your domain, with priorities (lower is preferred). Your email provider (Google Workspace, Microsoft 365, Zoho, Fastmail…) gives the exact values.

SPF: who may send

One TXT record listing the services allowed to send as your domain:

@ TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"

• Only one SPF record per domain; merge services into it.
• SPF has a limit of 10 DNS lookups; too many include:s break it.

DKIM: signed messages

Each sending service gives you a public key to publish, usually as a TXT or CNAME record at a selector such as resend._domainkey. Receivers use it to verify messages were not altered and really came from an authorised service.

DMARC: policy and reports

_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@pandadevhub.com"

DMARC tells receivers what to do when SPF/DKIM checks fail and align with the visible From domain:

1. Start with p=none and read the reports to find every legitimate sender.
2. Move to p=quarantine, then p=reject once all your senders pass.

Major mailbox providers now expect bulk senders to have SPF, DKIM and DMARC in place.

Use a subdomain for app email

Send transactional email from a subdomain such as mail.pandadevhub.com. Its reputation is separate from your staff mailboxes, and its records do not clash with your main email provider.

Exercise

Publish SPF, DKIM and a p=none DMARC record for a domain or subdomain, send test messages to a Gmail account and check "Show original" for SPF, DKIM and DMARC passes.

Check yourself

• Why must a domain have only one SPF record?
• What does DKIM prove?
• Why start DMARC at p=none?