Two SPF records
A second v=spf1 record for a new service makes SPF fail for all your mail.
Merge them into one record with a single all at the end.
v=spf1 include:a.com include:b.com ~allCheck a domain’s email setup in seconds. See its MX, SPF, DKIM and DMARC records, what each one means, and what to fix.
DNS shows how a domain is configured. It can’t confirm that your mail is actually signed, passes DMARC alignment, or reaches the inbox. Lookups run in your browser through Google Public DNS, with Cloudflare DNS as a fallback.
Four DNS records decide whether a domain can receive mail and whether other servers can trust mail that claims to come from it. The checker reads each one, explains it and flags what’s missing or wrong.
MX records name the servers that receive mail for the domain, in order of priority. We check that each one resolves and recognise the email provider behind them.
Receiving mailSPF lists the servers allowed to send mail as your domain. We follow every include, count DNS lookups against the limit of 10 and check the policy at the end.
Sender authorizationDKIM publishes a public key that receivers use to verify your messages weren’t altered. We look up your selector, read the key type and size, and spot revoked or weak keys.
Message integrityDMARC tells receivers what to do with mail that fails SPF and DKIM, and where to send reports. We read every tag and follow the current standard, RFC 9989.
Spoofing protectionOptional records that ask senders to deliver over encrypted connections only, and to report when they can’t. We show whether they’re published.
Encrypted deliveryWhere the domain’s DNS is hosted, whether its answers are cryptographically signed, and whether it publishes a brand logo record for supporting inboxes.
Additional insightsIt takes a few seconds. You don’t need an account or access to the domain’s settings, because the records are public.
Type a domain like yourcompany.com. You can also paste a website address or an email address; we use only the domain.
Each check gets a status: Pass, Warning, Problem, Not checked or Not applicable. Open the raw records to see exactly what DNS returned.
Make the suggested changes at your DNS host, wait for them to take effect (usually minutes, sometimes a few hours), then run the check again.
Most issues come from adding a new service without updating the records that are already there.
A second v=spf1 record for a new service makes SPF fail for all your mail.
Merge them into one record with a single all at the end.
v=spf1 include:a.com include:b.com ~allEvery include, a, mx and redirect costs a lookup, and includes nest. Over 10, SPF fails.
Drop services you no longer use, or replace includes with their IP ranges.
Receivers decide alone what to do with spoofed mail, and you get no reports.
Publish a starter record with a report address.
v=DMARC1; p=none; rua=mailto:dmarc@you.comp=none only monitors. Mail that spoofs your domain still gets delivered.
When reports show your services pass, move to quarantine, then reject.
Many providers don’t sign your mail until you turn DKIM on and publish their key.
Microsoft 365: add two selector CNAMEs. Google Workspace: add the TXT key.
After a switch, old MX records still send some mail to the service you left.
Keep only your current provider’s MX records and remove the rest.
Since 2024 the largest mailbox providers have required email authentication. Google started rejecting more non-compliant mail in November 2025, and Microsoft’s rules for Outlook.com took effect in May 2025.
DNS shows how a domain is configured, not how a particular message was handled.
Whether your mail is actually DKIM-signed and passes alignment. That shows in the Authentication-Results header of a real message.
Whether mail reaches the inbox. That also depends on sending reputation, content and how recipients engage.
Whether your domain or sending servers are listed on a spam blocklist.
Whether your mail servers are online and accept encrypted connections.
It reads a domain’s public DNS records that control email (MX, SPF, DKIM and DMARC) and tells you whether they’re present, valid and set up in a way receivers expect. It’s a configuration check: it shows how the domain is set up, not how a particular message was handled.
It’s free and needs no account. The lookups run in your browser and go to Google Public DNS, or Cloudflare DNS if Google doesn’t answer. We don’t store the domains you check. If you enter an email address, only the part after the @ is used.
DKIM keys are published under a name called a selector, which your email provider chooses. DNS doesn’t list them, so no tool can find every key from the domain alone. We try the selectors common providers use. If none match, enter your selector: it’s in your provider’s DKIM settings, or after s= in the DKIM-Signature header of an email you sent.
Both are fine. -all asks receivers to reject mail from servers you didn’t list, and ~all asks them to accept it but treat it as suspicious. With DMARC in place, receivers mostly act on your DMARC policy instead. Avoid +all, which allows any server to send as you.
It’s the right first step, and it’s all Gmail and Yahoo require from bulk senders. But p=none only monitors: spoofed mail is still delivered. Use the reports to confirm your legitimate mail passes, then move to quarantine and reject.
To evaluate SPF, receivers may make at most 10 DNS lookups, counting include:, a, mx, ptr, exists and redirect, including those inside included records. Beyond 10, SPF returns a permanent error and fails. The checker counts them for you and shows the full include tree.
DNS answers are cached for the time set in each record (its TTL), often between a few minutes and a day. If you just made a change, wait and check again. Also confirm you edited the DNS host your nameservers point to, which the report lists under Additional insights.
Not necessarily. Correct DNS records let receivers verify your mail, which you need to reach the inbox, but filtering also depends on your sending reputation, your content and how recipients interact with your messages.
A null MX record (0 .) says a domain doesn’t accept email (RFC 7505). It’s the correct setup for domains that never use email. Pair it with “v=spf1 -all” and a DMARC record with p=reject so nobody can send mail as that domain either.
Free, with no signup. They all run in your browser.
When you connect your domain, Atomic Mail shows you the MX, SPF, DKIM and DMARC records to add. Mail between your team is end-to-end encrypted, with no ads and no tracking.
Business
Free tools
Features
Compare
Learn
© 2026 Atomic Mail. All rights reserved.
AtomicMail Systems OÜ, Harju maakond, Tallinn, Kesklinna linnaosa, Harju tn 3 // Vana-Posti tn 2, 10146