Email DNS records explained: which ones do you need?

Email depends on a handful of DNS records, and most email problems trace back to one of them being missing, duplicated or mistyped. This page is the map: what each record does, what it looks like, which ones you actually need, and where to go for the details.

Every example uses example.com and illustrative values. Copy real values from your mail provider's admin console.

What DNS records does email need?

Email needs an MX record to receive mail and three authentication records to send it reliably: SPF, DKIM and DMARC. Everything else on this page either is managed by your provider (PTR) or is an optional extra that strengthens security or branding (MTA-STS, TLS-RPT, BIMI).

A note on names: most DNS hosts want only the part before your domain in the host field. Type _dmarc, not _dmarc.example.com, or you may create _dmarc.example.com.example.com. @ means the domain itself.

What does an MX record do?

An MX (mail exchanger) record tells other mail servers which host receives email for your domain. Senders look it up for every message they deliver to you, try the lowest priority number first, and fall back to higher numbers if that fails. Change your MX and you change where all your inbound mail goes.

Microsoft's external DNS records reference gives the Microsoft 365 target as <MX token>.mail.protection.outlook.com with a TTL of 3600. Google's MX setup page says "the Google Workspace MX record value is smtp.google.com" with priority 1, and that domains that started before 2023 may have older values beginning aspmx, which still work. If you use an inbound filtering service, your MX points to that service instead, and it delivers clean mail to your mailboxes.

Microsoft adds a caution worth repeating: "You can have multiple MX records; however, that can cause problems for mail delivery." Our guides on what an MX record is and MX priority and backup MX explain why, and how to change MX records without losing email covers switching providers.

A domain with no MX record isn't safe from mail. RFC 7505 explains that senders fall back to the domain's A or AAAA address when no MX exists. A domain that should never receive mail can publish a null MX, 0 ., which tells senders "there exists no mail exchanger for a domain". See null MX records.

What is an SPF record?

An SPF (Sender Policy Framework) record is a TXT record at your domain that lists the servers allowed to send mail using your domain in the envelope sender address. Receivers compare the connecting server's IP address with the list and get a pass, fail, softfail or neutral result.

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all"

The rules that trip people up: there can be only one SPF record ("you can only have a single SPF record for your domain", in Microsoft's words), and evaluating it can't take more than 10 DNS lookups. Two records cause a PermError, covered in multiple SPF records. Syntax is explained in SPF record syntax and examples, and SPF records by provider lists the include for each common service.

SPF checks the envelope sender (Return-Path), not the From address people see. That difference matters for DMARC and is explained in Return-Path vs From address.

What is a DKIM record?

A DKIM (DomainKeys Identified Mail) record publishes the public key receivers use to verify the signature your mail service adds to each message. It lives at selector._domainkey.yourdomain, where the selector is a label chosen by the sending service. RFC 6376 section 3.6.2.1 stores all DKIM keys in a subdomain named _domainkey.

google._domainkey.example.com.     TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft.

Unlike SPF and DMARC, you can have many DKIM records, one per selector, so each sending service can have its own. Some providers ask for a TXT record containing the key; others ask for a CNAME that points to a key they host. DKIM CNAME vs TXT records explains the difference, and DKIM records by provider lists the exact records for common services.

What is a DMARC record?

A DMARC record is a TXT record at _dmarc.yourdomain that tells receivers what to do with mail whose From domain fails both aligned SPF and aligned DKIM, and where to send reports. It is what turns SPF and DKIM into protection against someone spoofing your exact domain.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

The policy p= is none (monitor), quarantine or reject. RFC 9989 requires v=DMARC1 to be the first tag and says that if "multiple DMARC Policy Records are returned for a single target, they are all discarded." Subdomains without their own record inherit the parent domain's. What DMARC is covers the concept, and DMARC record examples covers every tag.

What is a PTR record, and who sets it?

A PTR (pointer) record is a reverse DNS record that maps a sending server's IP address back to a host name. Receivers check that it exists and that the host name resolves back to the same IP. Unlike the other records here, it lives in the IP owner's DNS, not your domain's zone.

Google's email sender guidelines say all senders must "ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records." If you send through Microsoft 365, Google Workspace or a sending platform, the provider manages PTR for its own servers. If you run your own mail server, ask your hosting or internet provider to set it. See reverse DNS PTR records for mail servers and check yours with the PTR Lookup.

What other DNS records does email use?

Beyond the core four, email uses several optional or platform-specific records: MTA-STS and TLS-RPT for encrypted delivery, BIMI for brand logos, autodiscover for mail app setup, verification records for providers, and sometimes a custom bounce domain.

MTA-STS and TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security) tells senders to deliver to you only over verified, encrypted connections. RFC 8461 uses two parts: a TXT record at _mta-sts.example.com such as v=STSv1; id=20160831085700Z;, and a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt with a mode of enforce, testing or none. TLS-RPT (RFC 8460) is a TXT record at _smtp._tls.example.com, for example v=TLSRPTv1;rua=mailto:reports@example.com, that asks senders for daily reports of TLS problems. See MTA-STS and TLS-RPT explained.

BIMI

BIMI (Brand Indicators for Message Identification) is a TXT record at default._bimi.example.com that points to your logo and, for Gmail, a certificate file. Supporting mailbox providers show the logo only when the domain enforces DMARC with p=quarantine or p=reject; Google's BIMI setup page says "the policy option (p) must be set to quarantine or reject." See BIMI explained.

Autodiscover, verification and bounce domains

• Autodiscover helps Outlook find the right server. Microsoft lists a CNAME with alias Autodiscover and target autodiscover.outlook.com as one of "the three primary records that all customers should use", along with MX and SPF.
• Domain verification TXT records prove you own the domain when you add it to a provider. Microsoft says its verification record "doesn't affect anything else." Leave old ones in place only for providers you still use.
• Custom bounce or Return-Path domains are a subdomain, such as bounce.example.com, with its own MX, SPF or CNAME records, used by sending platforms so bounces come back to a domain you control and SPF can align for DMARC.

What does a complete set of email DNS records look like?

Here is an illustrative zone for a domain using Microsoft 365 for mailboxes and one marketing platform. Values are examples only:

example.com.                       MX     0 example-com.mail.protection.outlook.com.
example.com.                       TXT    "<domain verification string from Microsoft 365>"
example.com.                       TXT    "v=spf1 include:spf.protection.outlook.com include:mail.marketing.example ~all"
autodiscover.example.com.          CNAME  autodiscover.outlook.com.
selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.contoso.n-v1.dkim.mail.microsoft.
mk1._domainkey.example.com.        TXT    "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.                TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_mta-sts.example.com.              TXT    "v=STSv1; id=20261103T000000;"
_smtp._tls.example.com.            TXT    "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Notice what's single and what's multiple: one MX here, one SPF, one DMARC, but three DKIM selectors and several TXT records at the root. That's normal. SPF is identified by its v=spf1 prefix, so other TXT records at the root don't conflict with it.

Which email DNS records are required?

For a domain that sends and receives business email, treat MX, SPF, DKIM and DMARC as required. Large mailbox providers now enforce authentication. Google's sender guidelines require all senders to "set up SPF or DKIM email authentication", and for bulk senders, more than 5,000 messages a day to Gmail accounts, SPF and DKIM and DMARC, with the From domain "aligned with either the SPF domain or the DKIM domain." Our guide to Gmail, Yahoo and Microsoft bulk sender requirements covers each provider's rules.

For a domain that never sends or receives mail, publish the defensive set instead: a null MX, v=spf1 -all and v=DMARC1; p=reject, with no DKIM. Protecting parked domains from spoofing explains why.

How do I add and check email DNS records?

1. Find your DNS host. Look up your domain's NS records. Edit the zone wherever they point, which may not be your registrar.
2. Collect the exact values from each provider's admin console. Don't retype long values by hand; copy and paste them.
3. Add MX and SPF first, then DKIM for each sending service, then DMARC with p=none and a rua address.
4. Enter only the host part (_dmarc, selector1._domainkey) unless your host's help says otherwise.
5. Respect the TTL. Changes reach receivers only after cached copies expire. See DNS TTL and MX change propagation.
6. Check everything with the Email Health Check, or the Microsoft 365 & Google Workspace DNS Setup Checker if you use either platform.
7. Send a test message to an outside mailbox and confirm spf=pass, dkim=pass and dmarc=pass in the headers.

Step-by-step instructions exist for common DNS hosts, including Cloudflare, GoDaddy and Namecheap. For a new domain, follow the full new domain email setup checklist.

Next steps

• Run the Email Health Check on each domain you own and fix anything missing or duplicated.
• Write down which service each SPF include and DKIM selector belongs to, so you can remove records when you stop using a service.
• Watch for changes. iBlockSpam's domain monitoring alerts you when your MX, SPF or DMARC records change: weekly on Protect, daily on Protect Plus.

Browse our other email basics guides.