Below are six key email security protocols that email marketers should implement in their email systems. They help email service providers (ESPs) verify legitimate senders, protect your domain from impersonation, and maintain secure email delivery.
1. SPF – Sender Policy Framework
SPF tells receiving mail servers which servers are authorized to send email on behalf of your domain.
For example, suppose you send an email from news@yourcompany.com to a Gmail user. When Gmail receives the message, it can check the SPF record published in your yourcompany.com DNS and ask:
“Is the server that sent this email authorized by this domain?”
If the sending server is authorized in the SPF record, the SPF check can pass.
In simple terms, SPF is your domain publishing a list of approved email senders.
If you use an email included with your web hosting package, such as email provided through a hosting control panel, the hosting provider may automatically create an SPF record for you.
If you use a third-party email service such as Google Workspace, Amazon SES, SendGrid, or another ESP, check your provider’s docs and make sure its sending servers are authorized in your domain’s SPF record.
Your provider may give you an SPF value similar to:
v=spf1 include:emailprovider.com -all
Then add this as a TXT record in your domain’s DNS:
- Type: TXT
- Host: @
- Value: v=spf1 include:emailprovider.com -all
Mistakes to avoid
Do not create multiple SPF records for the same domain.
If several services send email using your domain, their authorized senders normally need to be combined into a single SPF record. For example: v=spf1 include:emailprovider.com include:otheresp.com -all
SPF also has a limit of 10 DNS-lookup-causing mechanisms during authentication, so adding many email services can eventually cause SPF to fail.
2. DKIM – DomainKeys Identified Mail
SPF verifies the sending server. DKIM adds another layer by attaching a cryptographic signature to the email.
Behind the scenes, your email provider signs the message using a private key. The receiving mail server then retrieves the corresponding public key from your DNS and uses it to verify the signature.
In simple terms:
SPF asks: “Is this server authorized to send for this domain?”
DKIM asks: “Can this email prove that it was signed by the domain?”
For example, you might have a mailbox hosted by Namecheap or another hosting provider but use Amazon SES, SendGrid, Resend, or another ESP to send your marketing campaigns.
In that situation, the ESP normally provides DKIM records that you add to your domain’s DNS.
A DKIM record may look similar to:
- Type: TXT
- Host: selector1._domainkey
- Value: [public DKIM key supplied by your email provider]
The ESP keeps the private key and uses it to sign outgoing messages. Gmail, Yahoo, and other receiving systems can then retrieve the public key from DNS to verify the signature.
For example, if Amazon SES is sending your campaign, SES signs the message. Gmail receives the message, finds the DKIM public key published for your domain, and checks whether the signature is valid.
DKIM is extremely important for bulk email. Gmail currently requires bulk senders sending to personal Gmail accounts to authenticate with both SPF and DKIM.
So if you are sending newsletters or marketing campaigns through an ESP, DKIM should be configured before you start sending.
3. DMARC – Domain-based Message Authentication, Reporting and Conformance
DMARC tells receiving mail providers what to do when an email claiming to come from your domain fails authentication and, importantly, whether the authenticated domain matches the domain shown to the recipient in the From: address.
For example, if your newsletter email shows:
From: news@yourcompany.com
Gmail can check SPF and DKIM and then determine whether the authentication results are properly aligned with yourcompany.com.
DMARC therefore works roughly like this:
SPF + DKIM
↓
DMARC checks authentication and alignment
↓
Apply the domain’s DMARC policy
DMARC is published as a DNS TXT record at:
- Type: TXT
- Host: _dmarc
- Value: v=DMARC1; p=none;
The p=none policy tells receiving systems to monitor DMARC failures without asking them to quarantine or reject the messages based on that policy.
A simple way to verify DMARC authentication is to send an email to a Gmail account, open the message, and select Show original.
You should see authentication results similar to:
- SPF: PASS
- DKIM: PASS
- DMARC: PASS
4. ARC – Authenticated Received Chain
ARC is useful when an email passes through another mail system before reaching the recipient. For example, forwarding services
Email gateways, Security systems, etc.
Example ARC flow:
Original sender
↓
Email gateway
↓
Forwarding service
↓
Gmail
It allows participating mail systems to record: “This is what authentication looked like when I received the message.”
Unlike SPF, DKIM, and DMARC, ARC is generally handled by the mail infrastructure that processes or forwards the message.
If your company operates its own mail infrastructure or runs a service that forwards or modifies email, your technical team may need to configure ARC signing and validation.
For most marketers simply sending newsletters through an ESP, ARC is something to understand rather than to implement.
5. BIMI – Brand Indicators for Message Identification
BIMI is the protocol that connects email authentication with brand identity.
It allows mailbox providers like Gmail to display your brand logo instead of a generic avatar.
BIMI implementation requires:
- SPF and/or DKIM authentication
- DMARC deployment
- A properly prepared SVG logo
- A BIMI DNS record
- A Verified Mark Certificate (VMC) or Common Mark Certificate (CMC)
To get a Verified Mark Certificate (VMC) for your email, you must legally trademark your logo and purchase the certificate from an authorized provider like GlobalSign at a cost of about 1500/yearly. However, Common Mark Certificates (CMCs) provide another route for eligible logos without a trademark requirement. Google now supports CMCs for Gmail.
Once you have the above, the implementation is as simple as adding a TXT record just like DMARC.
- Type: TXT
- Host: default._bimi
- Value: v=BIMI1; l=https://yourcompany.com/logo.svg; a=https://yourcompany.com/certificate.pem
This is probably out of the reach of many marketers because of the processes involved to obtain a VMC. It is also not an email delivery requirement.
6. MTA-STS – Mail Transfer Agent Strict Transport Security
While SPF, DKIM, and DMARC help establish whether email claiming to come from your domain is legitimate, MTA-STS helps protect the connection used when mail servers deliver email to each other.
To implement MTA-STS, you need to publish an MTA-STS DNS record:
- Type: TXT
- Host: _mta-sts
- Value: v=STSv1; id=2026080801
You also need to host an HTTPS policy file with values that look like this:
- version: STSv1
- mode: enforce
- mx: mail.yourcompany.com
- max_age: 86400
Create and upload file: https://mta-sts.yourcompany.com/.well-known/mta-sts.txt with the above policies
MTA-STS is not normally something your email marketing platform needs to configure for sending your campaigns.
For example, if you use an ESP to send emails from: newsletter@yourcompany.com
MTA-STS isn’t what tells Gmail: “This ESP is allowed to send my newsletter.”
That’s primarily where SPF, DKIM, and DMARC come in.
MTA-STS is concerned with the mail server receiving email for your domain and the security of the connection used to deliver that email.
The easiest way to remember the difference is to think about the specific question each protocol answers:
| Protocol | What it does |
| SPF | Can emails be send from this server using my my domain? |
| DKIM | Can this email prove it was signed by me |
| DMARC | Does the authentication align with my From domain, and what should happen if it fails |
| ARC | Can I verify what authentication happened earlier in the email’s journey |
| BIMI | Can my authenticated brand logo be displayed in the inbox |
| MTA-STS | When delivering email to my domain, must the connection meet my TLS security requirements |
For most email marketers, SPF, DKIM, and DMARC are the only protocols that you need to ensure that they are correctly implemented, as they affect email deliverability.
