What email DNS records are needed for a domain?

Every domain that sends or receives email needs an MX record (which mail servers handle inbound mail) and, to prevent spoofing, SPF, DKIM and DMARC records. MX is required for receiving. SPF, DKIM and DMARC are required to pass authentication checks and keep your emails out of spam folders.

What is the difference between SPF, DKIM and DMARC?

SPF (Sender Policy Framework) lists which IP addresses and servers are allowed to send mail for your domain. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each email that recipients verify against a public key in your DNS. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do with messages that fail SPF or DKIM, and is the policy that ties them together.

How do I set up SPF, DKIM and DMARC records?

Add three TXT records in your DNS provider: an SPF record like "v=spf1 include:_spf.google.com ~all", a DKIM record with the name selector._domainkey.yourdomain.com containing the public key from your email provider, and a DMARC record with the name _dmarc.yourdomain.com like "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com". Start with p=none in DMARC, monitor reports, then tighten the policy.

Can I have multiple SPF records?

You should have only one SPF record per domain. Multiple SPF records cause the DNS lookup to fail with a 'permerror' and can make receiving servers reject your mail. If you need to authorize multiple services, combine them into a single SPF record with multiple include: mechanisms. The SPF specification allows a maximum of 10 DNS lookups per record.

Email DNS Records Explained — SPF, DKIM, DMARC, MX

Email relies entirely on DNS. Before a single message reaches an inbox, the sending and receiving mail servers consult your domain's DNS records — MX records to find where to deliver mail, TXT records to verify the sender is legitimate, and more.

If your email DNS records are missing or misconfigured, you will face two problems. First, legitimate messages may land in spam or bounce entirely. Second, attackers can forge emails that look like they come from your domain and use your brand to run phishing scams.

This guide explains the four email DNS records you need — MX, SPF, DKIM and DMARC — how they work, what each one protects against, and how to configure them step by step.

MX Records — Routing Inbound Mail

The MX (Mail Exchange) record tells other mail servers where to deliver email addressed to your domain. When someone sends a message to user@yourdomain.com, their mail server queries your domain's MX records to learn which mail servers accept inbound mail for you.

Each MX record has a priority number. Lower numbers indicate higher priority. Sending servers always try the lowest-priority server first and only fall back to higher numbers if the primary is unavailable. This gives you built-in redundancy — you can run a primary mail server and one or more backups.

A typical Google Workspace MX setup looks like this:

10 ASPMX.L.GOOGLE.COM 20 ALT1.ASPMX.L.GOOGLE.COM 20 ALT2.ASPMX.L.GOOGLE.COM 30 ALT3.ASPMX.L.GOOGLE.COM

When you switch email providers, you replace the MX records at your DNS host. This is one of the few DNS changes that takes effect quickly even with caching, because mail servers re-query MX records on every delivery attempt. Make sure the old provider's MX records are completely removed before you cut over, otherwise some mail will still route to the old servers.

You can check a domain's current MX records with our DNS lookup tool — select the MX record type and enter the domain name.

SPF Records — Authorizing Senders

SPF (Sender Policy Framework) publishes a list of IP addresses and servers that are allowed to send email on behalf of your domain. It lives in a TXT record and answers one question: "who is authorized to send mail from this domain?"

When a receiving server processes a message, it looks up your SPF record, extracts the IP address of the sending server, and checks whether that address is in the list. If the sender is not authorized, the email fails SPF authentication.

A basic SPF record looks like this:

v=spf1 include:_spf.google.com include:spf.mandrillapp.com ~all

The include: mechanism lets you authorize entire ranges of IPs published by a third-party service like Google or Mailchimp. The ~all (soft fail) at the end is the policy for anything not listed — soft fail means "probably not authorized". You can also use -all (hard fail), which is stricter and rejects all unlisted senders.

Critical rules: you may only have one SPF record per domain, and it may contain a maximum of 10 DNS lookups. Every include: and redirect: counts toward that limit. Exceeding it causes a permanent error and your domain will fail SPF checks. If you need more than 10 lookups, use subdomain SPF records to break the domain up.

SPF is a solid first line of defense, but it has a weakness: it only checks the envelope sender. An attacker who cannot spoof the return-path of your domain can still spoof the From address that shows in the email client. That is why SPF is always paired with DKIM and DMARC.

DKIM Records — Digital Signatures

DKIM (DomainKeys Identified Mail) attaches a unique cryptographic signature to every message your domain sends. The signature is created with a private key held by your email provider, and the matching public key is published in your DNS as a TXT record.

Receiving mail servers fetch the public key from your domain, decrypt the signature, and confirm the message was not modified in transit and genuinely came from your domain. If the signature does not verify, DKIM authentication fails.

DKIM uses a selector, which is a label that points to the specific key. The DNS name for a DKIM record looks like this:

google._domainkey.yourdomain.com

Here, google is the selector. Your email provider gives you the selector name and the public key value. You add them as a TXT record with that exact DNS name. The value looks like a long base64 string:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Selectors let you rotate keys without downtime — you publish the new key under a new selector, sign messages with it, then remove the old selector once all mail has ceased being signed with the old key. Keys that are exposed or compromised can be revoked simply by deleting the selector's TXT record.

Unlike SPF, DKIM is not limited to 10 lookups and there is no limit on the number of DKIM records you can have. Different subdomains and different senders each use their own selector.

DMARC Records — Enforcing Policy

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the enforcement layer that ties SPF and DKIM together. It tells receiving servers what to do with messages that fail both authentication checks, and it gives you visibility into who is sending mail from your domain through aggregated reports.

A DMARC record is a TXT record published under the special name _dmarc.yourdomain.com. A standard policy looks like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

The p= tag is the policy. There are three options, from least to most strict:

p=none — take no action, just generate reports. Use this during rollout to observe traffic.
p=quarantine — send failing mail to the spam folder. This is the recommended policy for most domains.
p=reject — block failing mail entirely. This is the strongest protection but should only be enabled after monitoring reports confirm persistent support.

The rua= tag specifies the address where DMARC will send daily aggregated reports — a summary of how many messages passed and failed and from which sources. The adkim= and aspf= tags control whether the domain alignment must be strict (s) or relaxed (r).

DMARC requires that either SPF or DKIM passes AND that the domain in the message aligns with your authenticated domain. Even when both pass individually, if the alignment is wrong (for example a third party sending as your subdomain), DMARC fails. This is what definitively stops domain spoofing.

How to Set Up Email DNS Records Step by Step

Configure these records in your DNS provider's control panel (Cloudflare, Google Domains, GoDaddy, Cloudflare Pages, your registrar, or your hosting provider). The steps are the same almost everywhere.

Step 1 — Verify current records

Before changing anything, check what already exists using our DNS record lookup. Look for existing MX, SPF (v=spf1), DKIM (v=DKIM1) and DMARC (v=DMARC1) records so you do not overwrite working configuration.

Step 2 — Configure MX records

Ask your email provider for their MX server hostnames and priorities. Remove old MX records, then add the new ones exactly as provided.

Step 3 — Publish SPF

If you already have an SPF record, edit it and append new include: mechanisms rather than adding a second record. If you have no record, create one TXT record like v=spf1 include:_spf.google.com ~all, replacing the include with your provider's value.

Step 4 — Publish DKIM

Generate the key in your email provider's admin console (for Google Workspace, that is under Apps > Gmail > Authenticate email). Copy the selector and the public key, then add a TXT record with the name selector._domainkey and the value starting with v=DKIM1; k=rsa; p=.... Wait for DNS propagation, then click "Start authentication" in the provider.

Step 5 — Publish DMARC

Add a TXT record with name _dmarc and value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Monitor the aggregated reports you receive for about two weeks. Once you confirm legitimate mail always passes, upgrade to p=quarantine, then p=reject.

Step 6 — Test everything

Use our DNS checker to confirm all records resolve. Then send test messages with GlockApps or Mail-Tester to verify SPF, DKIM and DMARC all pass before mailing real customers.

Common Email DNS Mistakes to Avoid

Multiple SPF records. The most common and most damaging mistake. A domain with two SPF records fails permanently. Everything fails, including legitimate mail. Always merge into one record.

Wrong DKIM selector name. The selector must match exactly. If your provider generated selector k1, the DNS name is k1._domainkey.yourdomain.com. A missing or slightly wrong name means a permanent DKIM failure.

Overlapping -all too soon. Switching DMARC from none to reject before verifying auxiliary services (newsletter tools, transactional senders) send from your domain will cause their mail to be blocked. Audit reports first.

Ignoring subdomains. Whatever you do at the apex domain, decide how subdomains are handled. Some providers generate DMARC reports for subdomains you never send from. You can publish a policy for subdomains using the sp= tag in the DMARC record.

Missing PTR records. While not part of SPF, DKIM or DMARC, many mail servers also require a forward-confirmed reverse DNS (FCrDNS) check. Reverse DNS must map your mail server's IP back to its hostname, or some recipients will reject your mail outright regardless of SPF/DKIM/DMARC.

Tools to Verify Your Email DNS Setup

You have several reliable ways to verify your configuration. For instant checks, our DNS lookup tool can query all the record types discussed here — MX, TXT and A records — against any domain.

For a full message-level test, send a test email and check the authentication headers or use MXToolbox, which provides free SPF, DKIM and DMARC validators and a comprehensive domain health check.

If you are building the mail side of a monitored setup, the records also matter for DNS monitoring — you want alerts when a DKIM key or DMARC policy changes unexpectedly, since a sudden p=reject can break a business overnight.