SPF, DKIM and DMARC checker
The test reads a domain's DNS records and tells you what is missing, what is wrong and what you need to change. Free, no sign-up, no email address required.
An SPF record defines which servers may send for a domain. A DKIM key lets receivers verify the signature of a message. A DMARC record determines what should happen to messages that pass neither SPF nor DKIM, and where the reports about them go. All three are TXT records in DNS, and this test checks all three in one pass, together with the MX records for receiving mail.
Check a domain
The test queries three places in DNS: the domain itself for SPF and the MX records, _dmarc.yourcompany.com for the policy, and <selector>._domainkey.yourcompany.com for the key. Only publicly available records are read.
Report by email, if you like
The result is shown above, in full and with nothing asked in return. If you also need it in writing, for example to pass on to the person who manages your DNS, we will send it to you by email.
What the test checks
SPF: which servers may send for your domain
An SPF record is a TXT record in DNS that names the servers allowed to send for a domain. The receiver compares the IP address the message came from with this list. If it does not match, that is a red flag.
The test checks more than whether the record exists. It counts the DNS lookups the record triggers, because RFC 7208, section 4.6.4, allows exactly ten. Anyone above that gets a PermError at every receiver, and then the record acts as if it did not exist. The test also checks whether there is exactly one record, which qualifier is at the end, and whether it contains outdated mechanisms such as ptr.
DKIM: the signature receivers verify
A DKIM key is a public key in DNS that receivers use to check the signature of a message. The signature is created when the message is sent, using the matching private key. If it checks out, the message was not altered on the way.
This is where every checking tool reaches its limit: the key sits under a freely chosen name, the selector, and DNS does not allow listing the names that exist. The test therefore tries 24 selectors that common providers use. If it finds none, that does not mean the domain does not use DKIM. It only means the name was not among the ones checked. Enter it above, and it will be found. For a key it finds, the test checks the length, whether it has been revoked, and whether it is in test mode.
DMARC: the rule for failed checks
A DMARC record is a TXT record under _dmarc that defines what happens to messages that fail SPF and DKIM. It also names the address receivers send their reports to.
The test reads the policy, checks the order and validity of the tags, and tells you whether a report address is set. It follows RFC 9989 from May 2026: pct is reported as obsolete instead of as a valid intermediate step, and it knows t=y and np. If a subdomain has no record of its own, it looks for the record of the parent domain and tells you which one actually applies. That is the most common reason for the false "no DMARC" message from other tools.
The three records at a glance
| Host | Type | Example value | Purpose |
|---|---|---|---|
yourcompany.com |
TXT | v=spf1 include:spf.spamgo.de ~all |
Names the servers allowed to send |
mb1._domainkey.yourcompany.com |
TXT | v=DKIM1; k=rsa; p=MIIBIjAN… |
Public key for the signature |
_dmarc.yourcompany.com |
TXT | v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com |
Policy and report address |
Many providers expect only the part in front of the domain in the host field, so @ for the domain itself and _dmarc instead of _dmarc.yourcompany.com. If the record shows up doubled after saving, for example as _dmarc.yourcompany.com.yourcompany.com, that was the cause.
What a result looks like
Checked on August 18, 2026, domain mailbridge.email, our own:
| Record | Finding | What the test says |
|---|---|---|
| SPF | passed | Record present, ends in -all, triggers 5 of 10 allowed DNS lookups. |
| DKIM | not found | None of the 24 selectors checked exists. That is no proof that DKIM is missing. |
| DMARC | error | There is a TXT record at _dmarc.mailbridge.email, but it is not a DMARC record: the SPF value was pasted there by mistake. |
| MX | passed | One mail server, reachable. |
Grade D, one error and one warning. We are deliberately keeping this example instead of making up a clean one: the error is real, and it shows exactly the kind of slip you do not notice without a check. A TXT record was present in the right place, just with the wrong content, and every tool that only reports "no DMARC found" sends you looking in the wrong direction.
Passed, warning, error: what the three states mean
- Passed means: checked and in order.
- Warning means: it works, but something is missing or only half effective. A missing DMARC record is listed here, because no rule requires one, but without it the domain has no protection against forgery.
- Error means: the record is broken or harmful. Two SPF records on one domain belong here, because the check then fails at every receiver, and so does
+all, because it explicitly allows forgery. - Unknown means: the lookup itself did not work. That says something about DNS at that moment, not about the domain. In that case the test never claims a record is missing.
Error messages and what they mean
| Message | Meaning | What to do |
|---|---|---|
| PermError | The SPF record cannot be evaluated at all, usually because of too many DNS lookups or two records. | Consolidate lookups, remove extra records. |
| TempError | The check was temporarily not possible, for example because a name server did not respond. | Check again later. If it keeps happening, a name server is broken. |
SoftFail (~all) |
The sender is not listed, but the receiver should still accept the message and flag it. | Nothing. This is the recommended setting for normal operation. |
Fail (-all) |
The sender is not listed and should be rejected. | Only set it when every sending system really is in the record. |
Neutral (?all) |
The record makes no statement. That makes it practically useless. | Change it to ~all. |
| None | The domain has no SPF record at all. | Create one, see the table above. |
| No matching DKIM selector | There was no key under the names checked. The selector may still exist. | Read your own selector from a message you sent and enter it above. |
DMARC without rua |
A policy is set, but no address for the reports. | Add rua=mailto:…. Without reports you cannot see what fails. |
| Alignment not met | SPF or DKIM passed, but for a different domain than the one in the visible From field. | Bring the sender domain and the checked domain into line. |
Common mistakes in the records
Two SPF records on one domain
Exactly one record per domain is allowed. Two almost always come about when a new service is added and its record is placed next to the existing one instead of into it. The result is a PermError, and the domain is then worse off than without any SPF record. The fix is to merge both into one and list the include: entries one after another.
More than ten DNS lookups in SPF
Every include:, every a, mx, ptr and exists costs one DNS lookup, and the lookups of the included records count too. If you list Microsoft 365, a newsletter tool and a web shop one by one, you quickly end up at twelve. At eleven it is over: receivers abort with a PermError, and the whole record stops working. This test counts the lookups for you and shows which entry causes how many. If you bundle your sending through a relay, a single include: replaces all of these entries.
The DKIM record is in the wrong place
The key belongs at <selector>._domainkey.yourcompany.com. Often the ._domainkey part is missing, or the provider appends the domain a second time. By the way, an empty value after p= is not a mistake but the intended form for a revoked key.
DMARC stays at p=none
Starting with p=none is right, but it is not the goal. As long as the policy stays there, anyone can send in your name without a receiver doing anything about it. Once the reports show over a few weeks that all of your own senders pass, move to p=quarantine and later to p=reject.
Add a missing record
- Log in to the provider that manages your domain's DNS zone. That is the provider where the domain is registered, or the one whose name servers it points to.
- Open the DNS record management and find the section for TXT records.
- Enter the missing record with host, type and value exactly as the test shows it. For SPF the host is the domain itself, for DMARC it is
_dmarc. - Save and wait until the change is visible. That usually takes a few minutes, in rare cases up to 24 hours.
- Check the domain here again. If the finding stays the same, look at whether the host was written twice, for example
_dmarc.yourcompany.com.yourcompany.com.
The detailed order for a switchover without delivery failures, with every field explained, is in the guide Set up SPF, DKIM and DMARC.
What does p=none mean in DMARC?
p=none means that receivers should take no action when a message fails the check. The message is delivered as usual. The only benefit lies in the reports: you find out who sends in your name before you block anything. As a permanent setting p=none offers no protection, as a starting point it is exactly right.
Why does my mail land in spam despite SPF?
SPF is only one of several signals. The most common reasons despite a valid SPF record are: the record triggers more than ten DNS lookups and therefore fails completely, DKIM is missing, the sender address in the visible From field does not match the checked domain, or the sending IP address has a poor reputation. This test shows the first three. For reputation, see the guide IP or domain on a blacklist.
How do I find my domain's DKIM selector?
The selector is in the header of every signed message. Open a message you sent yourself, show its headers and look for the DKIM-Signature line. The value after s= is the selector. The name cannot be listed in DNS, which is why no checking tool can guess it reliably.
How long does it take for a DNS change to take effect?
Usually a few minutes, in rare cases up to 24 hours. What matters is the TTL of the old record: for that long a resolver may still answer with the previous value from its cache. A new record where nothing existed before is usually visible right away.
Do I need DKIM if SPF is set up?
Yes. SPF only checks which server a message came from, and that check breaks with every forwarding. DKIM signs the message itself and survives forwarding. DMARC counts as passed when one of the two matches, which is why the two methods together make delivery stable.
Is the test free?
Yes, with no sign-up and no email address required. Only public DNS records are queried. We keep no list of the domains that were checked. Exactly what is transmitted is described in the privacy policy.
How MailBridge takes care of SPF, DKIM and DMARC
MailBridge is an SMTP relay: devices and applications hand their mail to our servers, and those take care of sending it through your sender domain. For the three records, that means three things. For SPF, a single include: covers all of our servers, no matter how many there are and whether we replace one. We sign DKIM ourselves: you add one record and never have to generate or rotate a key. You still create your DMARC record yourself, and no provider can do that part for you.
In the portal, the record found and the record expected are shown side by side for every domain, with a copy button for host, type and value. All domains are checked again daily, and if a record breaks later, it shows up as an action item.
Standards and status of this page
This page is published by MailBridge, a service of LOGIN SystemHaus GmbH in Wiesbaden, Germany. All servers are located in Germany.
The methods checked are defined in RFC 7208 (SPF, 2014), RFC 6376 (DKIM, 2011) and RFC 9989 (DMARC, May 2026). RFC 9989 has superseded RFC 7489: pct has been dropped, the test mode t=y takes its place, and np for non-existent subdomains is now part of the core. The test rates records accordingly. The limit of ten DNS lookups and that of two empty lookups are in RFC 7208, section 4.6.4. The recommendation to avoid ptr is in RFC 7208, section 5.5. Under RFC 2181, section 10.3, an MX record must point directly to a name with an address, not to an alias. The explicit statement that a domain accepts no mail is defined in RFC 7505.
Last checked on August 28, 2026.