What is SPF?

SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from [email protected], it checks your domain's SPF record to see if the sending server's IP is on the approved list. If not, the message is more likely to be marked as spam or rejected.

SPF is published as a TXT record at your domain's root. A typical SPF record for Google Workspace looks like: v=spf1 include:_spf.google.com ~all.

What is DKIM?

DKIM (DomainKeys Identified Mail) is an email authentication method that cryptographically signs your outgoing messages so receivers can verify they weren't tampered with in transit. Your mail provider generates a public/private key pair — the private key signs outgoing email, and the public key is published in your DNS as a TXT record at a specific selector subdomain like google._domainkey.yourdomain.com.

Receiving servers fetch the public key, verify the signature, and use the result as one signal of whether the message is legitimate. DKIM works alongside SPF and DMARC for full email authentication.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy that tells receiving mail servers what to do when an email fails SPF or DKIM authentication — and where to send reports about authentication failures. It builds on SPF and DKIM rather than replacing them.

A basic DMARC record looks like: v=DMARC1; p=none; rua=mailto:[email protected]. The policy (p=) can be none (monitor only), quarantine (send suspicious mail to spam), or reject (block outright).

What's the difference between SPF, DKIM, and DMARC?

SPF lists which servers can send mail for your domain, DKIM cryptographically proves a message wasn't altered, and DMARC tells receivers what to do when SPF or DKIM checks fail and asks for reports.

Think of it this way:

• SPF = the guest list. "These servers are allowed to send mail from my domain."
• DKIM = the tamper-proof seal. "This message arrived exactly as I sent it."
• DMARC = the rulebook plus the audit. "If the guest list or the seal fails, here's what to do — and send me a report."

All three are DNS records. Together they form the modern email authentication stack and are required by major providers like Google and Yahoo for bulk senders.

Why are my emails going to spam?

The most common cause is missing or misconfigured email authentication — specifically SPF, DKIM, or DMARC. Receiving mail servers (Gmail, Outlook, etc.) score every message and route low-scoring ones to the spam folder. Missing authentication, mismatched sender domains, low reputation, or spam-like content all drag the score down.

To diagnose, check your domain with a tool like MXHelper's free checker. You'll typically see one or more of these:

• No SPF record — receiving servers can't verify your sending servers
• No DKIM signature — messages aren't cryptographically signed
• No DMARC policy — your domain is vulnerable to spoofing
• Sending from a server not in your SPF record

Fix the authentication first, then look at content (no spammy phrases, balanced text-to-link ratio, plain-text version included).

How do I check my domain's email authentication?

Use a free DNS lookup tool that queries your SPF, DKIM, and DMARC records. MXHelper does this in one click — enter your domain and it checks all three authentication mechanisms plus MX records, with plain-English explanations of any issues found.

You can also check manually with dig or nslookup:

• SPF: dig TXT yourdomain.com
• DMARC: dig TXT _dmarc.yourdomain.com
• DKIM: dig TXT <selector>._domainkey.yourdomain.com (selector varies by provider)

Why is my SPF record failing?

The four most common reasons SPF fails are:

• Multiple SPF records on the same domain — only one is allowed. Merge them into a single record with multiple include: mechanisms.
• More than 10 DNS lookups — SPF has a hard limit. Each include:, a, mx, etc. counts. Exceeding it causes a permerror.
• Sending from a server not in the record — typically happens when adding new transactional email services (Mailchimp, SendGrid, etc.) without updating SPF.
• Syntax errors — missing v=spf1 prefix, typos in includes, or improperly quoted records.

What's the SPF 10-lookup limit?

SPF records are limited to 10 DNS lookups during evaluation; exceeding the limit causes the entire SPF check to fail with a "permerror." Each include:, a, mx, ptr, and exists: mechanism in your record counts as a lookup, and nested include: mechanisms count cumulatively.

If you hit this limit, options include: removing unused includes, using SPF flattening services (which expand includes into IP ranges at the cost of maintenance burden), or consolidating sending services.

How do I set up DMARC?

Add a TXT record at the _dmarc subdomain of your domain with a value like v=DMARC1; p=none; rua=mailto:[email protected].

Step by step:

• Log into your DNS provider (Cloudflare, GoDaddy, Namecheap, etc.)
• Add a new TXT record
• Host/Name: _dmarc (most providers auto-append the domain)
• Value: v=DMARC1; p=none; rua=mailto:[email protected]
• Save and wait for DNS propagation (usually under an hour)

Start with p=none for monitoring only. After reviewing reports for 2-4 weeks, tighten to p=quarantine or p=reject. MXHelper will generate the exact record for you based on a short form.

What's the difference between p=none, p=quarantine, and p=reject?

These three DMARC policies tell receiving mail servers how to handle messages that fail authentication.

• p=none — monitoring only. Receivers report on failures but don't take action. Use this when first deploying DMARC.
• p=quarantine — failing messages go to the spam folder. Use this once you've reviewed reports and fixed legitimate senders.
• p=reject — failing messages are blocked outright. Strongest protection against spoofing; only use when you're confident all your legitimate sending sources pass authentication.

Most domains progress through none → quarantine → reject over weeks or months as you gain confidence.

What does ~all vs -all mean in SPF?

~all is a "soft fail" — receivers should accept the message but mark it as suspicious. -all is a "hard fail" — receivers should reject the message outright.

Most domains should start with ~all while building confidence that all legitimate senders are listed in the record. Once you're certain, switching to -all provides stronger anti-spoofing protection. There's also ?all (neutral, no opinion) and +all (allow anything, never use this).

What's a DKIM selector?

A DKIM selector is a label that identifies which DKIM public key to use, allowing a domain to publish multiple DKIM keys at the same time. The full DNS location for a DKIM record is <selector>._domainkey.<domain>, for example google._domainkey.example.com.

Different mail providers use different selectors:

• Google Workspace: google
• Microsoft 365: selector1 and selector2
• Zoho: configurable, often zoho
• Mailgun, SendGrid, etc.: each generate their own

Multiple selectors let you sign mail from multiple sending services without conflict.

Can I have multiple SPF records on a domain?

No. RFC 7208 explicitly forbids having more than one SPF record per domain, and most mail receivers will treat multiple records as a permerror (causing all SPF checks to fail).

If you need to authorize multiple sending services, combine them into a single SPF record using multiple include: mechanisms, for example: v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all.

Do I need all three: SPF, DKIM, and DMARC?

Yes, for serious email deliverability you should publish all three. Each protects against different attacks:

• SPF protects against unauthorized servers sending as your domain
• DKIM protects against messages being modified in transit
• DMARC ties them together with an enforcement policy and reporting

As of 2024, Google and Yahoo require all three for senders who deliver more than 5,000 messages per day to their users. Even for low-volume domains, having all three significantly improves deliverability and protects against spoofing.

What is an MX record?

An MX (Mail Exchanger) record is a DNS entry that tells the internet which mail servers are responsible for receiving email for your domain. When someone sends a message to [email protected], their server queries your MX records to find where to deliver it.

MX records have a priority value — lower numbers are preferred. For example, Google Workspace uses MX records like 1 aspmx.l.google.com, 5 alt1.aspmx.l.google.com, and so on. The primary mail server is tried first; backups are tried only if the primary is unreachable.

How long does DNS propagation take?

DNS changes typically propagate within 15 minutes to a few hours, though the technical maximum is determined by your record's TTL (time-to-live) value.

In practice:

• Most modern DNS providers (Cloudflare, AWS Route 53, Google Cloud DNS) propagate changes in under 5 minutes
• Legacy registrars with longer TTLs (1 hour, 24 hours) take longer
• Browser and OS DNS caches can hold old values for a few hours regardless of TTL
• Some ISPs and corporate networks cache DNS more aggressively

To force-test, use a public DNS resolver like dig @1.1.1.1 yourdomain.com to bypass local caches.

Is MXHelper free?

Yes, MXHelper is completely free with no signup required. The site is supported by unobtrusive advertising. There's no premium tier or paywall — every feature is available to every visitor.

Does MXHelper store the domains I check?

No. We don't save the domain names you check in any database. Queries may appear briefly in standard web server access logs (which is true of every website) and are automatically deleted after 30 days. We use this only for aggregate traffic analysis and security diagnostics. See our privacy policy for full details.