SPF, DKIM and DMARC Check: Free Analysis

FOUR RECORDS

What are these four records for?

Together they define who may send email in your domain’s name. When they are missing two things happen at once: your own mail lands in spam, and someone else can send mail in your name.

MX · Who receives the mail

Tells which server receives mail addressed to your domain. Having a backup means mail is not lost when the first server does not answer.

SPF · Who may send

Lists which servers may send email in your name. Mail from a source outside the list cannot be verified on the receiving side.

DKIM · Was the message altered

Adds a cryptographic signature to each message. The recipient uses it to verify the message really came from you and was not altered in transit.

DMARC · What if verification fails

Says what to do with mail that fails SPF and DKIM: monitor, quarantine or reject. Set to reject, forged mail never reaches the recipient’s inbox.

Why it matters · It cuts both ways

With the records missing, the invoices, quotes and verification codes you send land in spam, and at the same time nothing stops a fake invoice being sent in your name.

Who sets this up · Together, at setup

The records are added in the panel where you manage your domain. We do this step together during MXGate setup, and if you prefer to do it yourself we give you the exact values in writing.

HOW IT WORKS

How SPF, DKIM and DMARC work

The SMTP protocol that carries email was designed in 1982 with no notion of verifying who the sender is: whatever a server writes on the “From” line is what the recipient sees. These three records are the layer added later, over DNS, to close that gap. Below is first what the receiving server does in order, then what each record actually contains.

The message arrives: envelope and header are two different thingsSMTP

The sender information of an email sits in two places. The envelope (MAIL FROM, that is, Return-Path) carries the address used for server-to-server delivery; the header (From) carries the address the user sees on screen. The two can differ, and forgery uses exactly that gap.

SPF: may this server sendSPF

The receiving server takes the IP address that opened the connection and reads the SPF record of the envelope domain from DNS. If the IP is authorised in that record, SPF passes. SPF looks only at the envelope, never at the From line the user sees.

DKIM: does the signature holdDKIM

The sending server adds a cryptographic signature to the message and states which domain the signature belongs to in the d= tag. The recipient resolves the signature with the public key in that domain’s DNS. If the headers and body were not altered in transit, DKIM passes.

Alignment: is the verified domain the one on displayALIGNMENT

This is the crux. The envelope domain SPF verified, or the value in DKIM’s d=, must be the same domain as the From address the user sees. If it is not, alignment fails even when the check itself technically passed.

DMARC: the decisionDMARC

DMARC requires at least one of the two to both pass and be aligned. If that holds, the message passes DMARC. If not, the policy the domain owner wrote into the record applies: monitor, quarantine or reject.

Why SPF alone is not enough: an attacker can keep a flawless SPF record on their own domain, send from it and pass SPF, putting your name only on the From line. That is what the user sees. This is why DMARC handles alignment and the decision. A second point: when mail is forwarded the sending IP changes and SPF breaks, while the DKIM signature travels with the message and survives. That is why having both matters.

SPF · The sending authorisation record

It is written as a TXT record on the domain itself (the root). A domain can have only one SPF record; adding a second invalidates both.

WHAT THE RECORD CONTAINSSPF

v=spf1 include:spf.mxgate.com.tr ip4:203.0.113.10 ~all

v=spf1: States that the record is SPF and which version. Every SPF record begins with it, otherwise it is not recognised.
include:: Includes another domain’s SPF record here. This is the method used when you send through a provider; when the provider changes its servers you do not have to touch your record.
ip4: · ip6:: Authorises a single IP address or block directly. If you send from your own server, the address goes here.
a · mx: Treats the servers in the domain’s A or MX records as authorised. It looks short, but each one costs an extra DNS lookup.
~all: Soft fail for a source not on the list: the mail is usually still delivered but marked. Used during a transition period.
-all: A source not on the list is rejected. This is the correct end state, but move to it only once you are sure every sending source is listed: your marketing tool, your billing system, your ERP.

DKIM · The signing key record

Written as a TXT record under a selector name. The sending server generates the value; the private key stays on the server and only the public key goes into DNS.

WHAT THE RECORD CONTAINSDKIM

selector1._domainkey.ornek.com   IN TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

selector1: The selector: it lets several keys sit side by side on the same domain. The s= tag in the signature header tells the recipient which selector to read.
_domainkey: A fixed prefix that never changes. The full name is always <selector>._domainkey.<domain>.
k=rsa: The key type. RSA is the common one; some providers also offer Ed25519, but support on the receiving side is still limited.
p=: The public key itself. It is long and a single piece; no space or line break must slip in while copying. Prefer 2048 bits, as 1024 is now considered weak.
rotation: When a key is replaced, a second record is opened under a new selector, sending is switched to it and the old one is removed later. Messages already in flight keep verifying.

DMARC · The policy and reporting record

Written as a TXT record under the _dmarc subname. It combines the SPF and DKIM results with alignment and tells the recipient what to do.

WHAT THE RECORD CONTAINSDMARC

_dmarc.ornek.com   IN TXT   "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@ornek.com; adkim=r; aspf=r"

p=: The policy: none does nothing and only collects reports, quarantine moves mail to the spam folder, reject refuses delivery. You walk up through these three in order.
sp=: A separate policy for subdomains. If omitted, subdomains inherit the p= value. This matters when you also want to lock down subdomains you do not use.
rua=: The address for aggregate reports. Receiving servers send an XML report once a day listing every source that sent in your name and how verification went. This is where the real value of DMARC lies.
ruf=: The address for detailed reports on individual failures. Most receivers do not send these for privacy reasons, so add it without expecting much.
adkim= · aspf=: Alignment strictness. r (relaxed, the default) counts subdomains as a match; s (strict) requires an exact match. Stay on relaxed if you have systems that send from a subdomain.
pct=: The percentage of messages the policy applies to. Used to try a strict policy on a small share first and measure the effect before going all in.

The six most common mistakes

Two SPF records on one domain

Opening a second SPF record when adding a new provider is the most common mistake. The result is a permanent error and both records are treated as invalid. The correct move is to add an include: inside the existing record.
Exceeding the ten DNS lookup limit

An SPF evaluation may make at most ten DNS lookups, and every include:, a, mx and redirect counts against it. Once the limit is passed the record is not evaluated at all, leaving you no better off than a domain with no SPF.
Starting straight at p=reject

Mail from every system you forgot to list stops immediately, and that is usually the billing, HR or marketing tool, which takes days to notice. Watch the reports on p=none first.
Setting a report address and never reading the reports

The part of DMARC that does the work is the rua reports: there is nowhere else you can see who sends in your name. They arrive as XML and are not readable raw, so a parser is needed.
Forgetting subdomains

Protecting the root domain does not protect a subdomain you never use, such as billing.yourcompany.com. Unused subdomains are convenient targets for forgery, and sp= closes them.
Treating SPF as sufficient on its own

SPF breaks on forwarding and never checks the From line the user sees. Since February 2024 Google and Yahoo have required all three of SPF, DKIM and DMARC from senders of more than five thousand messages a day.

FAQ

Questions about the check

What does this check look at?

It reads your domain’s public DNS records: the MX records showing which server receives your mail, SPF defining who may send in your name, DKIM signing the message, and DMARC saying what to do with mail that fails verification. It never touches email content; it only makes DNS queries.

How is the score calculated?

The presence and configuration quality of four records are scored: an MX record and whether it is redundant, an SPF record and whether it uses a strict policy, a DMARC record and its policy, and a DKIM signature. Each critical issue found lowers the score. This is our own measure rather than an industry standard; its purpose is to show gaps, not to rank.

Are the results stored?

No. The query runs at that moment, the result is shown on screen and nothing is stored. We do not add your domain to a list, we do not email you and we do not ask you to sign up.

How do I fix what is missing?

SPF, DKIM and DMARC are added to your domain’s DNS records, which you do from the panel where you manage the domain. After the check, the values to enter for any missing record are generated for your domain and shown, and the recommendations link to the explanatory section on this same page. If you would rather not do it yourself, we do it together during setup.

I have an SPF record, so why does DMARC still fail?

Because DMARC looks at alignment as well as at the check passing. SPF verifies the envelope domain (Return-Path), not the domain in the From line the user sees. When the two differ, SPF technically passes but alignment fails and DMARC fails with it. This is common on domains that send through a marketing or billing service.

Is SPF alone enough without DKIM?

No. When mail is forwarded the sending IP changes and SPF breaks, while the DKIM signature travels with the message and survives. SPF also never checks the From line the user sees. Since February 2024 Google and Yahoo have required all three from senders of more than five thousand messages a day.

Let us close the gaps together

Adding the records is a few lines in a DNS panel, but a wrong value can stop your outgoing mail completely. We do this step together during setup.

Get in Touch How SPF, DKIM and DMARC work

Can your domain be impersonated?