Email Authentication Explained

Email authentication is a set of protocols that prove an email genuinely came from your domain and was not tampered with in transit. Without these protocols, anyone can send email that appears to come from your domain, enabling phishing, business email compromise, and brand damage. This guide covers the five protocols you need: SPF, DKIM, DMARC, MTA-STS, and BIMI.

1. SPF (Sender Policy Framework)

What it does

SPF is a DNS TXT record that lists every IP address and mail server authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from your domain, it checks this record and rejects or flags messages from unlisted sources.

How to set it up

Add a TXT record to your domain's DNS. The record lists your mail providers using include: mechanisms and ends with an -all (hard fail) or ~all (soft fail) directive.

Example record

Common mistakes

• Using +all or ?all instead of -all, which allows any server to pass SPF
• Too many DNS lookups - SPF has a 10-lookup limit; exceeding it causes the entire record to fail
• Multiple SPF records - only one TXT record starting with v=spf1 is allowed per domain
• Forgetting third-party senders - marketing platforms, CRM tools, and helpdesks often send on your behalf

How to verify

Use the free SPF checker to validate your record syntax, count DNS lookups, and confirm your senders are included.

2. DKIM (DomainKeys Identified Mail)

What it does

DKIM adds a cryptographic signature to every outgoing email. The sending server signs the message headers and body with a private key. The receiving server retrieves the matching public key from your DNS and verifies the signature, confirming the message was not altered in transit and genuinely originated from your domain.

How to set it up

Your email provider generates a DKIM key pair. You publish the public key as a DNS TXT record at a selector-specific subdomain. Each provider uses its own selector name.

Example record

DNS name: google._domainkey.yourdomain.com

Common mistakes

• Using 1024-bit keys - use 2048-bit RSA keys at minimum; 1024-bit keys can be cracked
• Not rotating keys - DKIM keys should be rotated at least annually
• Missing selectors - each sending service (Google, Mailchimp, etc.) needs its own DKIM selector published in DNS
• Truncated TXT records - long DKIM keys may be split incorrectly by DNS providers, breaking validation

How to verify

Send a test email and check the Authentication-Results header for dkim=pass. You can also query the DKIM selector directly with a DNS lookup on selector._domainkey.yourdomain.com.

3. DMARC (Domain-based Message Authentication, Reporting & Conformance)

What it does

DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when a message fails both checks. It also provides a reporting mechanism so you can see who is sending email using your domain, both legitimately and fraudulently.

How to set it up

Add a TXT record at _dmarc.yourdomain.com. Start with p=none to monitor, move to p=quarantine once you are confident, and finally p=reject for full protection.

Example record

DNS name: _dmarc.yourdomain.com

Common mistakes

• Staying on p=none forever - monitor mode provides visibility but zero protection against spoofing
• No reporting address - without rua=, you cannot see who is sending as your domain
• Jumping straight to p=reject - enforce too early and you may block your own legitimate email from third-party services
• Ignoring subdomains - add sp=reject to cover subdomains that do not send email

How to verify

Use the free DMARC checker to validate your record, check your policy level, and confirm reporting is configured correctly.

4. MTA-STS (Mail Transfer Agent Strict Transport Security)

What it does

MTA-STS tells sending mail servers that your domain only accepts email over encrypted TLS connections. Without it, an attacker performing a man-in-the-middle attack can force a downgrade to unencrypted SMTP, reading or modifying email in transit.

How to set it up

MTA-STS requires two things: a DNS TXT record at _mta-sts.yourdomain.com and a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

Example DNS record

DNS name: _mta-sts.yourdomain.com

Example policy file

Common mistakes

• Invalid HTTPS certificate on the mta-sts subdomain - the policy file must be served with a valid TLS certificate
• Mismatched MX hosts - the mx: entries in the policy must match your actual MX records
• Forgetting to update the id - change the DNS record's id= value whenever you update the policy file, or senders will use a cached version
• Skipping testing mode - use mode: testing first to receive TLS failure reports without rejecting mail

How to verify

Query the DNS TXT record at _mta-sts.yourdomain.com and fetch the policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Confirm the mode is set to enforce and the MX entries match your DNS.

5. BIMI (Brand Indicators for Message Identification)

What it does

BIMI displays your brand logo next to your emails in supporting inbox providers (Gmail, Yahoo, Apple Mail, and others). It serves as a visual trust indicator for recipients and requires DMARC enforcement as a prerequisite, creating a direct incentive to complete your authentication setup.

How to set it up

1. Ensure DMARC is set to p=quarantine or p=reject
2. Create your logo as an SVG Tiny PS file (the only accepted format)
3. Optionally obtain a Verified Mark Certificate (VMC) from a certificate authority - required by Gmail
4. Publish a DNS TXT record at default._bimi.yourdomain.com

Example record

DNS name: default._bimi.yourdomain.com

Common mistakes

• Wrong SVG format - BIMI requires SVG Tiny Portable/Secure (SVG Tiny PS), not standard SVG; most logos need conversion
• DMARC not enforced - BIMI will not work with p=none; you must be on quarantine or reject
• Missing VMC for Gmail - Gmail requires a Verified Mark Certificate; Yahoo and Apple display logos without one
• Logo not HTTPS - the SVG and VMC URLs must be served over HTTPS

How to verify

Query the DNS TXT record at default._bimi.yourdomain.com and confirm the SVG URL returns a valid SVG Tiny PS file over HTTPS. Send a test email to a Gmail or Yahoo account to see if the logo appears.

How all five protocols work together

These protocols form a layered defense. SPF verifies the sending server. DKIM verifies the message integrity. DMARC enforces a policy when both fail and provides reporting. MTA-STS ensures the delivery channel is encrypted. BIMI rewards full compliance with visible brand trust.

Recommended implementation order

1. SPF - identify all services that send email for your domain and publish a record with -all
2. DKIM - enable signing for every sending service and publish all selector public keys
3. DMARC (monitor) - publish with p=none and a rua= address; review reports for 2-4 weeks
4. DMARC (enforce) - move to p=quarantine, then p=reject once reports are clean
5. MTA-STS - set up the policy file and DNS record to enforce TLS for inbound mail
6. BIMI - publish your brand logo and optionally obtain a VMC for Gmail support

Check your email authentication

Use the free DMARC checker and SPF checker to validate your records, or run a full domain scan to audit email authentication alongside SSL, DNS, headers, and more.