One newsletter email carries several sender addresses, and each of them belongs to a domain. This post follows one email from your app to the reader's inbox and shows which Domain Name System (DNS) records prove that each of those domains is yours.
This post reflects the rules and standards as of October 2026. Mailbox providers change their sender requirements often, and every sending service names its settings differently. Check your provider's current documentation before you change your DNS.
The mental model: one email, several senders
When you send a newsletter, you probably think of one sender: the address in the "From" line, like news@example.com. A real email has more than one. It has the address the reader sees, a hidden return address for failed deliveries, a digital signature from whoever sent it, a reply address, and the web addresses of every link and image inside it.
Each of these points at a domain. For the most important ones, the receiving mail server asks the same question: is the owner of this domain really behind this message? You answer that question in advance, by publishing records in the domain's DNS. DNS is the public directory of the internet: anyone can look up a domain and read the records its owner put there.
An old paper letter is a good way to picture the parts:
- The envelope holds the delivery information. The post office reads it and never shows it to the reader. Its return address is where undelivered letters go back to.
- The letter inside has its own header: "From", "To", "Reply to". This is what the reader sees.
- A seal or signature proves who wrote the letter and that nobody changed it on the way.
- The content may send the reader somewhere else, like a link to a website.
Email works the same way, and the two "from" addresses (on the envelope and on the letter) do not have to match. That gap is exactly what spammers use, and what the checks in this post close.
The main idea of this whole post fits in a few sentences. Three of these domains are checked against their own DNS records: the return address, the From domain and the signing domain. The reply address is not checked at all, and the link domains are judged only by their reputation. The message is trusted only when the domain in the visible "From" line matches at least one of the domains that passed a check.
The rest of the post takes the parts one at a time, in the order a receiving server meets them.
DNS records: how you prove a domain is yours
You prove you control a domain by publishing records in its DNS. Only the owner (or someone the owner trusts) can change those records, so a record is a public statement from the owner. Email uses four kinds of records:
- MX record (mail exchanger). It says which servers accept incoming email for a domain.
example.com MX smtp.google.commeans "send mail for example.com to Google". - TXT record (text). It holds free text. Email authentication rules are written as TXT records.
- CNAME record (canonical name). It says "this name is an alias for that other name". When a sending service asks you to add a CNAME, you are pointing one of your names at the service. The service can then change the real record on its side without asking you again.
- PTR record (pointer, also called reverse DNS). It turns an IP (Internet Protocol) address back into a name. Your sending service manages this one for its own servers, so you don't publish it yourself.
A sending service is the company that actually delivers your newsletter: Mailchimp, Brevo, Amazon Simple Email Service (SES), Postmark, Resend and many more. When you sign up, the service gives you a list of DNS records to add. This post explains what each record on that list is for.
The journey of one newsletter
Before we look at each check, here is the whole trip of one message. Your app asks the sending service to deliver a newsletter. The service signs it and hands it to the reader's mail server, for example Gmail. Gmail then reads three things from DNS before it decides where the message goes.
The servers talk to each other with SMTP (Simple Mail Transfer Protocol), the protocol that moves email between servers.
Check 1 is called SPF, check 2 is DKIM, and check 3 is DMARC. The next sections explain them in that order.
SPF: which servers may send for the bounce domain
SPF (Sender Policy Framework) is a list of the servers that are allowed to send email for a domain. You publish the list as a TXT record. The receiving server compares the IP address of the server that is talking to it with that list.
The important detail is which domain SPF checks. SPF does not check the "From" address the reader sees. It checks the envelope sender, the hidden return address for bounces. In SMTP this address is sent with the MAIL FROM command. When the message arrives, the receiving server copies it into a header called Return-Path, so you will see it under that name when you open the source of an email. The SPF standard, RFC 7208, describes both identities SPF can check: this one and the name the server uses to greet the other server (the HELO name).
An RFC (Request for Comments) is a document published by the Internet Engineering Task Force (IETF), the group that writes internet standards.
An SPF record looks like this:
example.com. TXT "v=spf1 include:_spf.google.com include:spf.esp.example.net ~all"
Read it from left to right:
v=spf1says this is an SPF record.- Each
include:adds the list of another company. Here, Google's servers (for staff email) and the sending service's servers may send. ~allsays what to do with every other server: treat it as a "soft fail", which usually means "suspicious".-allmeans "hard fail": "this server is not allowed".
SPF has two rules that cause many problems:
- Only one SPF record per name. Two TXT records that both start with
v=spf1on the same name make SPF fail completely. To add a service, you edit the existing record. - At most 10 DNS lookups. Every
include:costs at least one lookup, and the included lists can include other lists. RFC 7208, section 4.6.4 says the receiver must stop after 10. If your record needs more, SPF fails, even for your real servers. Every service you add to the same record brings you closer to that limit.
SPF has one more weakness. By default, the sending service puts its own domain in the envelope, for example bounces.esp.example.net. SPF then passes, but it passes for the service's domain, not for yours. The reader's server learns "the sending service sent this", which is true, but says nothing about whether you did. The custom Return-Path fixes that.
The custom Return-Path: make SPF count for your domain
A custom Return-Path means the sending service uses an address on your domain as the envelope sender. You choose a subdomain that is used only for this, for example bounce.example.com, and point it at the service. Services call this setting by different names: "custom Return-Path", "custom MAIL FROM domain", "custom bounce domain" or "envelope domain". They are all the same thing.
The subdomain needs two records, because it has two jobs:
- An SPF record, so SPF passes for
bounce.example.comwhen the service's servers send. - An MX record, so the bounce reports that other servers send back to that address reach the sending service. The service reads them and stops sending to addresses that don't exist.
Amazon SES documents exactly these two records for its custom MAIL FROM domain:
bounce.example.com. MX 10 feedback-smtp.eu-west-1.amazonses.com
bounce.example.com. TXT "v=spf1 include:amazonses.com ~all"
Other services ask for a single CNAME instead, which points the whole subdomain at them. Then the service publishes the MX and SPF records on its side.
There is a second benefit. The SPF record of the sending service now lives on bounce.example.com, not on example.com. Your main SPF record does not need an include: for that service at all, so it stays far away from the 10-lookup limit. Many setup guides still tell you to add the include to your main record. With a custom Return-Path, that include is not needed for the newsletter.
DKIM: a signature that travels with the message
DKIM (DomainKeys Identified Mail) adds a digital signature to every message. The sending service signs the message with a private key that only the service has. You publish the matching public key in DNS. The receiving server uses the public key to check two things: that the signature was made by someone with the private key, and that the signed parts of the message did not change on the way. The standard is RFC 6376.
The signature is a header in the message:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
h=from:to:subject:date:list-unsubscribe:list-unsubscribe-post;
bh=...; b=...
Three parts of it matter here:
d=example.comis the signing domain. This is the domain DKIM proves something about.s=s1is the selector, a name for one key. A domain can have many keys at the same time, one per selector. The receiver finds the public key at<selector>._domainkey.<domain>, so here ats1._domainkey.example.com.h=lists the headers that the signature covers. If anything in these headers or in the body changes after signing (apart from small whitespace changes the standard allows), the check fails.
Most sending services ask you to publish the key as a CNAME:
s1._domainkey.example.com. CNAME s1.dkim.esp.example.net.
s2._domainkey.example.com. CNAME s2.dkim.esp.example.net.
With CNAMEs, the service keeps the real public key on its side. It can replace the key regularly (this is called key rotation) without asking you to edit DNS. Two selectors let it switch from the old key to the new one with no gap. If your service gives you a TXT record with the key itself instead, use a 2048-bit key when you can choose.
Like SPF, DKIM has a default that does not help you. If you skip this setup, many services sign with their domain (d=esp.example.net). The signature is valid, but again it only proves that the service sent the message, not that you did.
DKIM has one big advantage over SPF: the signature is inside the message, so it survives when the message passes through another server, as long as that server does not change the signed parts. SPF checks the IP address of the last server, so it breaks as soon as someone else forwards the message.
DMARC: connect the checks to the From address
DMARC (Domain-based Message Authentication, Reporting and Conformance) answers the question SPF and DKIM leave open: do the domains that passed have anything to do with the "From" address the reader sees? It also lets you tell receivers what to do when the answer is no, and asks them to send you reports.
Until May 2026, DMARC was described in RFC 7489. It is now an official IETF standard (a "Proposed Standard"); before, it was only an informational document. The new version is split into three documents: RFC 9989 for the core rules, RFC 9990 for aggregate reports, and RFC 9991 for failure reports.
Alignment: the "From" domain must match
DMARC looks at the domain in the visible From: header and compares it with the domains that passed SPF and DKIM. When they match, the check is aligned. A message passes DMARC when at least one of these is true:
- SPF passed, and the Return-Path domain is aligned with the From domain.
- DKIM passed, and the signing domain (
d=) is aligned with the From domain.
"Match" has two modes, and you choose one per check in your DMARC record:
- Relaxed (the default). The two domains only need the same organizational domain, which is the registered domain, such as
example.com. Sobounce.example.comis aligned withnews@example.com. - Strict. The two domains must be exactly the same.
bounce.example.comis then not aligned withexample.com.
Relaxed alignment is what makes the custom Return-Path work, so most domains keep the default.
The table below runs the same newsletter through common setups. "Service domain" means the sending service's own domain.
| Setup | SPF result | DKIM result | DMARC result |
|---|---|---|---|
| Service defaults: bounce address and signature both on the service domain | Passes for the service domain | Passes for the service domain | |
| Custom Return-Path only | Passes, aligned | Passes for the service domain | |
| Custom DKIM only | Passes for the service domain | Passes, aligned | |
| Custom Return-Path and custom DKIM | Passes, aligned | Passes, aligned | |
| Both custom, then forwarded by the reader's old address | Fails | Passes, aligned | |
| Both custom, then a mailing list adds a footer | Fails | Fails |
The first row is the surprise for most people: SPF and DKIM both pass, and DMARC still fails, because neither check passed for your domain. One aligned check is enough to pass, but set up both. If one of them breaks on the way, the other one still lets the message pass.
The DMARC record and its policy
You publish DMARC as a TXT record on the _dmarc name of your domain:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
p=is the policy: what the receiver should do with a message that fails.nonemeans "deliver it as usual, only report it".quarantinemeans "put it in the spam folder".rejectmeans "refuse it".rua=is the address that receives aggregate reports. Large receivers send one report per day. Each report lists the servers that sent mail with your domain in the From line, how many messages, and whether they passed SPF, DKIM and DMARC. The reports are XML (Extensible Markup Language) files, so most people send them to a service that turns them into charts.adkim=andaspf=choose the alignment mode for DKIM and SPF:rfor relaxed (the default) orsfor strict.sp=sets a different policy for subdomains, andnp=sets one for subdomains that don't exist at all. A spammer who sends frominvoices.example.comwhen that name does not exist is caught bynp=reject.
If a subdomain like news.example.com has no DMARC record of its own, the receiver looks higher up and uses the one at _dmarc.example.com.
Move to enforcement step by step
A DMARC policy of none protects nobody: it only reports. The protection starts at quarantine and reject. But if you jump to reject before every real sender is aligned, your own invoices or password-reset emails start to disappear. So the safe path is slow:
- Publish
p=nonewith arua=address. - Read the reports for a few weeks. Each sender you recognise (your staff email, the newsletter, the billing system, the help desk tool) must pass with alignment. Fix the ones that don't.
- Move to
p=quarantinein test mode witht=y. In test mode, receivers apply the policy one level below the one you wrote, soquarantinewitht=ystill acts likenone. Receivers that still follow the old RFC 7489 don't knowt=yand applyquarantinefully, so expect some failing mail to reach spam folders already. Watch the reports. - Remove
t=y, so failing messages go to the spam folder. - Move to
p=reject.
Older guides use pct= to apply the policy to only a percentage of messages. RFC 9989 removed pct=, together with rf= and ri=, and added t=y for the same "try it first" step.
Reply-To: where the answers go
Reply-To is a header that tells the reader's email app where to send a reply. When it is missing, replies go to the From address. It lets you send from one address and receive answers at another, for example:
From: Example News <news@example.com>
Reply-To: Ana from Example <ana@example.com>
Nothing checks that you own the Reply-To domain. SPF looks at the envelope, DKIM can protect the Reply-To header from changes but says nothing about who owns its domain, and DMARC looks only at the From domain. So two things follow:
- Reply-To can't fix a failing DMARC. Putting your own domain in Reply-To while the From line uses the service's domain does not make the message yours.
- Reply-To is a common phishing trick. A message from a real, aligned domain can still ask for replies at a stranger's address. This is why spam filters look harder at messages whose Reply-To domain has nothing to do with the From domain. Keep it on your own domain when you can.
The reply address must also be able to receive email. Its domain needs an MX record that points to a real mailbox. A newsletter from news@news.example.com on a subdomain with no MX record will lose every reply, which is a good reason to set a Reply-To on a domain that has a mailbox. Microsoft's requirements for high-volume senders also ask for a valid From and Reply-To that can receive replies. A noreply@ address works against this.
Tracking domains: links and the open pixel
Most sending services measure two things: who opened the email and who clicked a link. They do it by changing your message before they send it. Both changes put another domain into the email.
Click tracking. The service replaces every link with a link to its own redirect server. The new link contains a unique code for the reader and the original address. When the reader clicks, the redirect server records the click and sends the browser on to the real page.
Open tracking. The service adds a tiny invisible image, called a tracking pixel, with a unique address for each reader. When the reader's email app downloads the image, the service records an "open".
By default, both use the service's domain, which is shared by thousands of other customers. A custom tracking domain, such as click.example.com, makes the links show your own domain. Twilio SendGrid calls this "link branding" and explains why it helps: spam filters check the reputation of every domain in the links, and with a shared domain your reputation depends on the other customers.
You set it up with a CNAME:
click.example.com. CNAME links.esp.example.net.
Three details matter when you add a tracking domain:
- HTTPS (Hypertext Transfer Protocol Secure) needs a certificate. The reader's browser connects to
click.example.com, so somebody must hold a certificate for that name. The certificate is the file that proves to the browser that the server really isclick.example.com. Most services can create it for you after you add an extra DNS record. Without it, your links fall back to plain HTTP, and some browsers and email apps warn about them. - Use a subdomain only for tracking. A CNAME can't sit on the root
example.com, and the subdomain should not host anything else. Your website stays onwww.example.com. - Use your own domain in the link, not a link shortener. Spam filters distrust messages whose links all use a shared link-shortening domain.
Treat open counts with care. Apple's Mail Privacy Protection loads remote content, including tracking pixels, privately in the background, whether or not the person reads the message. Every reader who uses Apple Mail with this feature turned on looks like an "open", so open rates go up and mean less. Click counts are more useful, but they are not perfect either: some company security scanners follow every link in a message to check it before the employee sees it. Many newsletters now turn open tracking off and measure only clicks, which also collects less data about readers.
What Gmail, Yahoo and Outlook require
Since 2024, the biggest mailbox providers have turned this setup from good advice into a requirement. The strictest rules apply to bulk senders. Gmail and Outlook define a bulk sender as a domain that sends more than 5,000 messages a day to their users. Yahoo does not publish a number. Smaller senders should follow them too, because the same checks decide which folder their mail goes to.
- Gmail's email sender guidelines ask every sender for SPF or DKIM, valid forward and reverse DNS, and a secure (TLS, Transport Layer Security) connection. Bulk senders need both SPF and DKIM, plus DMARC, alignment between the From domain and the SPF or DKIM domain, one-click unsubscribe, and a spam complaint rate below 0.3%.
- Yahoo's sender best practices ask bulk senders for both SPF and DKIM, a DMARC policy of at least
p=nonethat passes with alignment, one-click unsubscribe, and unsubscribe requests handled within 2 days. - Microsoft's rules for Outlook.com, Hotmail and Live, in force since May 2025, ask for SPF, DKIM and DMARC with at least
p=noneand alignment, plus From and Reply-To addresses that can receive replies, and a visible unsubscribe link. Messages that don't comply go to the Junk folder. Microsoft said rejection may follow later.
One-click unsubscribe is defined in RFC 8058. The message carries two headers. With them, Gmail and others show an "Unsubscribe" button next to the sender's name. When the reader presses it, the mailbox provider sends a request to your link (an HTTP POST request, the same kind a web form sends), and the reader never has to open a web page:
List-Unsubscribe: <https://example.com/unsubscribe?u=abc123>, <mailto:unsubscribe@example.com?subject=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
RFC 8058 also says the message must carry a valid DKIM signature that covers both headers. That is why the h= list in the DKIM example earlier includes them. One more reason a newsletter needs DKIM.
The rules side by side, for bulk senders:
| Requirement | Gmail | Yahoo | Outlook |
|---|---|---|---|
| SPF | |||
| DKIM | |||
DMARC, at least p=none | |||
| From domain aligned with SPF or DKIM | |||
| One-click unsubscribe | |||
| Spam complaints below 0.3% |
Use cases: how the pieces fit together
The parts above combine in different ways depending on what your domain sends. Here are the setups that come up most often.
Newsletter and transactional email from the same company
Transactional email is the mail a person expects because of something they did: a receipt, a password reset, a login code. It must arrive. A newsletter is marketing, and some readers will mark it as spam. Mailbox providers keep a reputation score for each sending domain. If both kinds of mail share one domain, the newsletter's complaints can push your password resets into the spam folder.
The usual answer is one subdomain per kind of mail, each with its own Return-Path, DKIM keys and tracking domain. This limits the damage but does not separate the two completely, because mailbox providers also look at the main domain.
With relaxed alignment, all of these align with the organizational domain example.com, and one DMARC record at _dmarc.example.com covers all of them. Many teams also use two different sending services, or two separate accounts at one service, so a problem with one kind of mail does not touch the other. Transactional mail usually has no tracking at all.
Staff email and a newsletter service on one domain
A small company often sends staff email through Google Workspace or Microsoft 365, and the newsletter through a separate service, all from example.com. Many sending services tell you to add their include: to your root SPF record, next to Google's, and there can be only one SPF record. The common mistake is then to add a second v=spf1 record. The other common mistake is to keep adding include: entries until SPF needs more than 10 lookups.
With a custom Return-Path for the newsletter, the problem goes away. The root SPF record lists only the staff email servers. The newsletter's SPF lives on bounce.example.com, a different name.
example.com. TXT "v=spf1 include:_spf.google.com ~all"
bounce.example.com. CNAME bounce.esp.example.net.
Mail that is forwarded or sent to a mailing list
Forwarding breaks SPF. When a reader forwards their old university address to Gmail, the university's server sends the message on to Gmail. The envelope still says bounce.example.com, but the connecting server is the university's, which is not in your SPF list. DKIM survives, because the signature is inside the message and the forwarder did not change it.
Mailing lists are harder. A list often adds [list-name] to the subject or a footer to the body. That changes signed parts of the message, so DKIM fails too, and with both checks failing, DMARC fails. Two fixes exist:
- The list rewrites the From line to its own address, for example
From: Ana via Book Club <bookclub@lists.example.org>. The message is now the list's own message and passes the list's checks. - ARC (Authenticated Received Chain), defined in RFC 8617. Each server on the way records the authentication results it saw when the message arrived, and signs that record. The final receiver can then trust that the message passed DKIM before the list changed it. ARC is an experimental standard. Large receivers such as Gmail use it, but whether they trust a given list is their decision.
A domain that never sends email
Spammers like domains that send no email, because their owners don't watch them. If you own example-shop.com only to redirect it to your main site, publish records that say it never sends mail:
example-shop.com. MX 0 .
example-shop.com. TXT "v=spf1 -all"
_dmarc.example-shop.com. TXT "v=DMARC1; p=reject"
The first line is a "null MX", defined in RFC 7505: this domain accepts no email. The second says no server may send for it. The third asks receivers to reject anything that claims to come from it.
The full DNS setup for one newsletter
Here is everything from this post together, for a company that uses Google Workspace for staff email and a sending service for a newsletter on news.example.com. The values on the right side of each CNAME come from your sending service, so yours will look different.
; Staff email: incoming mail and SPF for the root domain
example.com. MX 1 smtp.google.com.
example.com. TXT "v=spf1 include:_spf.google.com ~all"
; Newsletter: custom Return-Path (bounce domain)
bounce.news.example.com. CNAME bounce.esp.example.net.
; Newsletter: DKIM public keys, rotated by the sending service
s1._domainkey.news.example.com. CNAME s1.dkim.esp.example.net.
s2._domainkey.news.example.com. CNAME s2.dkim.esp.example.net.
; Newsletter: tracking domain for links (and the open pixel)
click.news.example.com. CNAME links.esp.example.net.
; One DMARC policy for example.com and all its subdomains
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"
The newsletter itself is sent with these headers. The Reply-To points at example.com, which has an MX record, so replies reach a person:
From: Example News <hello@news.example.com>
Reply-To: hello@example.com
List-Unsubscribe: <https://news.example.com/unsubscribe?u=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
When something fails: how to check
The fastest check is the received message itself. In Gmail, open the message, choose "Show original", and look at the Authentication-Results header. The receiving server writes the result of every check there:
Authentication-Results: mx.google.com;
dkim=pass header.i=@news.example.com header.s=s1;
spf=pass smtp.mailfrom=bounce.news.example.com;
dmarc=pass (p=QUARANTINE) header.from=news.example.com
Read it with this post in mind. smtp.mailfrom is the Return-Path domain that SPF checked. header.i is the domain DKIM checked. header.from is the visible From domain that DMARC compares both of them with.
To read your published records, use dig in a terminal:
dig +short TXT example.com # SPF for the root domain
dig +short CNAME bounce.news.example.com # custom Return-Path
dig +short TXT s1._domainkey.news.example.com # DKIM public key (follows the CNAME)
dig +short TXT _dmarc.example.com # DMARC policy
The problems below cause most failures. Each one comes from a part this post has already covered.
| What you see | Likely cause | Fix |
|---|---|---|
spf=permerror | Two SPF records on one name, or more than 10 lookups | Merge into one record. Move the newsletter to a custom Return-Path. |
| SPF and DKIM pass, DMARC fails | Both passed for the sending service's domain, not yours | Set up the custom Return-Path and custom DKIM. |
dkim=fail only for some readers | A mailing list changed the message | Expected for mailing lists. The list should rewrite the From line or add ARC headers. |
| DMARC reports show an unknown server sending as you | A tool you forgot (billing, help desk, a sales tool) or a spammer | Set up the tool with aligned DKIM, or let your DMARC policy block the spammer. |
| No "Unsubscribe" button in Gmail | Missing List-Unsubscribe-Post header, or DKIM does not cover it | Add both headers and sign them. |
| Links show a warning or do not use HTTPS | The tracking domain has no certificate | Turn on the service's certificate option for the tracking domain. |
| Replies to the newsletter bounce | The Reply-To (or From) domain has no MX record | Set a Reply-To on a domain with a real mailbox. |
A few related standards protect other parts of the email system. MTA-STS (Mail Transfer Agent Strict Transport Security) and TLS-RPT (TLS Reporting) make sure mail to your domain travels encrypted, and report when it does not. BIMI (Brand Indicators for Message Identification) shows your logo next to messages that pass DMARC at quarantine or reject. All three build on the setup in this post.
The short version
A newsletter carries several domains: the visible From, the Return-Path for bounces, the DKIM signing domain, the Reply-To, and the tracking domain in the links. SPF proves that the server may send for the Return-Path domain. DKIM proves that the signing domain signed the message and that nobody changed it. DMARC connects those results to the From line and tells receivers what to do when they don't match. The Reply-To is not checked by anyone, so keep it on your own domain and make sure it has a mailbox. The tracking domain does not change authentication, but every link is then judged by your own domain's reputation, not a shared one.
References
- RFC 7208, Sender Policy Framework (SPF) for Authorizing Use of Domains in Email — IETF
- Using a custom MAIL FROM domain — Amazon SES Developer Guide
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures — IETF
- RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — IETF, May 2026
- RFC 9990, DMARC Aggregate Reporting — IETF, May 2026
- Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders — Microsoft Outlook Blog
- How to set up link branding — Twilio SendGrid Docs
- Use Mail Privacy Protection on iPhone — Apple Support
- Email sender guidelines — Gmail Help
- Sender Best Practices — Yahoo Sender Hub
- RFC 8058, Signaling One-Click Functionality for List Email Headers — IETF
- RFC 8617, The Authenticated Received Chain (ARC) Protocol — IETF
- RFC 7505, A "Null MX" No Service Resource Record for Domains That Accept No Mail — IETF