Your email works. You send a quote to a client, they never reply, and weeks later you learn it landed in their junk folder — or was never delivered at all. Nothing in your inbox told you. This is the most common and least visible failure in business email, and in almost every case it traces back to three DNS records that were never set up properly: SPF, DKIM and DMARC. This guide explains what each one actually proves, how to set all three up correctly, the mistakes that quietly break them, and why passing all three still is not the whole story.
Quick Answer
SPF lists which servers are allowed to send email using your domain. DKIM adds a cryptographic signature proving the message really came from you and was not altered in transit. DMARC tells receiving servers what to do when SPF or DKIM fails, and sends you reports so you can see who is sending as your domain. You need all three: SPF and DKIM are checks, DMARC is the policy and the visibility. Set up in that order, start DMARC at p=none, read the reports for two to four weeks, then tighten to quarantine and finally reject.
What Each Record Actually Proves
SPF — Which Servers May Send as You
SPF (Sender Policy Framework) is a single DNS TXT record listing the mail servers permitted to send using your domain. When a receiving server gets a message claiming to be from you@yourcompany.ae, it looks up your SPF record and checks whether the connecting server appears on that list.
A typical record looks like this:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~allRead it left to right: this is SPF version 1, Google’s servers may send, Microsoft’s servers may send, and anything else should be treated as suspicious (~all, “soft fail”). The final mechanism matters more than people expect — see the mistakes section below.
What SPF does not prove: that the message content is genuine, or that the visible “From” address is honest. SPF checks the envelope sender, which is not the address your recipient sees. On its own it is a weak signal, and that is precisely why DKIM and DMARC exist.
DKIM — The Message Came From You and Was Not Altered
DKIM (DomainKeys Identified Mail) signs outgoing messages with a private key held by your mail provider. The matching public key sits in your DNS. The receiving server fetches that public key, verifies the signature, and learns two things at once: the message genuinely originated from a system authorised to sign for your domain, and the signed parts were not modified along the way.
DKIM is stronger than SPF because it survives forwarding. When a recipient auto-forwards your message, the connecting server changes and SPF breaks — but the DKIM signature travels with the message and still validates. If you have ever had mail rejected only when it was forwarded, this is why.
Your DNS entry is a TXT record on a selector, for example google._domainkey.yourcompany.ae. The selector name comes from your provider; you do not invent it.
DMARC — The Policy and the Reports
SPF and DKIM answer “did this pass?” Neither says what should happen when the answer is no. DMARC does, and it adds the part almost everyone skips: reporting.
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.ae; adkim=r; aspf=rp is the policy: none (monitor only), quarantine (send to junk), or reject (refuse delivery). rua is where aggregate reports are sent — daily XML summaries from every major provider showing exactly who sent mail claiming to be your domain and whether it passed.
DMARC also introduces alignment, which is the piece that catches most people. It is not enough for SPF or DKIM to pass; the domain that passed must match the domain in the visible “From” address. A message can pass SPF for your bulk-mail provider’s domain and still fail DMARC, because the address your recipient sees is yours, not theirs.
Why One Alone Is Not Enough
Each record covers a gap the others leave open.
SPF alone breaks on forwarding and says nothing about the visible sender. DKIM alone proves a signature but gives receivers no instruction when it fails, and no way to tell you it happened. DMARC alone is meaningless — it is a policy about two checks that must exist for it to evaluate.
Together they answer three separate questions: may this server send for you, is this message intact and genuinely yours, and what should happen, and who should be told, when the answer is no. Miss one and you have a gap someone can spoof through, or a failure you will never see.
Setting Them Up, In Order
Step one: inventory everything that sends mail as your domain. This is the step that gets skipped and the reason most rollouts break. Your mail provider is obvious. Less obvious: your website’s contact forms, your invoicing system, your CRM, your newsletter platform, your booking or support desk, and any legacy server still sending notifications. Every one of them must be authorised or it will start failing the moment you enforce a policy.
Step two: publish one SPF record. One — see the mistakes below. Include each sending service using the include: mechanism your provider documents, and end with ~all while you are still testing.
Step three: enable DKIM with every provider. Each generates a key and gives you a selector and a value to publish. Turn signing on only after the DNS record resolves, or you will sign with a key nobody can verify.
Step four: publish DMARC at p=none. This changes nothing about delivery. It only asks receivers to start reporting. Point rua at a mailbox you will actually read, or better, at a DMARC reporting service that turns the XML into something legible.
Step five: read the reports for two to four weeks. You are looking for legitimate senders that are failing — the invoicing system nobody remembered, the form plugin sending from the web server. Authorise each one. Only when the reports are clean should you move to p=quarantine, and later to p=reject.
Moving straight to reject without this observation period is the single fastest way to stop your own invoices from being delivered.
The Mistakes That Quietly Break Everything
More Than One SPF Record
A domain may publish exactly one SPF record. Two records is not “two lists that get combined” — it is a permanent error, and receivers treat the result as invalid. This happens constantly when a second provider is added and its record is published alongside the first instead of merged into it. Merge the include: mechanisms into a single record.
Exceeding Ten DNS Lookups
Every include:, a, mx and redirect in your SPF record costs a DNS lookup, and the specification caps the total at ten. Go over and the record fails — not for the eleventh sender, but entirely. Large providers nest their own includes inside yours, so four or five services is often enough to breach the limit. If you are near it, consolidate providers or use a service that flattens the record for you.
Ending With +all
This says “any server on the internet may send as my domain.” It is the opposite of the record’s purpose. Use ~all while testing and -all once you are confident. If you find +all on a domain you own, treat it as urgent.
Leaving DMARC at p=none Forever
This is the most common state we find, and it is a understandable one: p=none is safe, nothing breaks, and the reports pile up unread. But p=none instructs receivers to do nothing, which means anyone can still send mail as your domain and it will be delivered. Monitoring is a stage, not a destination.
Forgetting Subdomains
DMARC applies to subdomains unless you say otherwise with sp=. A domain enforcing p=reject with no subdomain policy will also reject mail from notifications.yourcompany.ae, which is often exactly where an application sends from.
Assuming the Records Are Still Correct
Providers change their sending infrastructure, services get replaced, marketing tools are trialled and forgotten. An SPF record written three years ago frequently authorises systems you no longer use and omits ones you do. Review it when anything about your mail setup changes.
How to Check Yours in Five Minutes
From any terminal:
dig +short TXT yourcompany.ae | grep spf1
dig +short TXT _dmarc.yourcompany.ae
dig +short TXT google._domainkey.yourcompany.aeRead the results against three questions. Is there exactly one SPF record, and does it end in ~all or -all? Does a DMARC record exist, and is its policy something other than none? Does your DKIM selector return a key?
The practical test is simpler still: send a message from your business address to a Gmail account you control, open it, and use “Show original”. Gmail displays SPF, DKIM and DMARC results in plain language at the top. Three passes is what you want. Anything else names the problem for you.
Authentication Is Necessary, Not Sufficient
Here is the part most guides leave out, and it costs businesses real delivery.
You can pass SPF, DKIM and DMARC perfectly and still land in spam. Authentication proves who sent the message. It says nothing about whether recipients want it. Receiving providers weigh sender reputation just as heavily, and reputation is built from signals you control differently: how many of your messages bounce, how often recipients mark you as spam, whether you send to addresses that no longer exist.
A high bounce rate is the fastest way to damage a domain’s standing, and it is usually caused by something mundane — a contact list that has not been cleaned in years, addresses collected without verification, or staff who left long ago. Providers read a sustained bounce rate as a sign of a list that was not gathered carefully, and they act on that reading regardless of how perfect your DNS is.
So treat authentication as the foundation and list hygiene as the ongoing discipline: remove hard bounces promptly, never buy lists, make unsubscribing easy, and send from an address that accepts replies. Our guide on choosing an email service for a small business covers the platform side of the same problem.
What This Looks Like for a UAE Business
Two details matter locally. First, if your domain was registered through a reseller and DNS is managed somewhere other than where your mail is hosted, the records must be published wherever your authoritative nameservers point — a surprising number of failed setups are simply records added in the wrong control panel. Second, if you run both a mail platform and a website that sends transactional messages from the same domain, both need authorising, and the website is the one people forget.
If you are moving providers, get authentication right before you cut over rather than after. Our email migration service handles the DNS side as part of the move, which avoids the window where mail authenticates against the old platform and fails against the new one.
Frequently Asked Questions
Will publishing these records stop people from spoofing my domain?
DMARC at p=reject stops spoofing that uses your exact domain in the visible “From” address, which is the form used in invoice-redirection fraud. It does not stop lookalike domains — an attacker registering a domain that differs by one character is unaffected, because they are authenticating their own domain honestly. Domain monitoring is a separate control.
How long do the records take to work?
DNS changes propagate within minutes to a few hours depending on your TTL. DMARC reports begin arriving within about 24 hours. The observation period before tightening policy is the long part, and it is measured in weeks, not because of DNS but because you need to see a full cycle of your organisation’s sending.
I use Microsoft 365 or Google Workspace. Isn’t this handled for me?
Partly. Both provide the values, and both enable DKIM readily, but neither can know about the other systems sending as your domain, and neither publishes your DMARC record for you. The defaults get you the platform’s own mail authenticated and nothing else.
Can I set p=reject straight away?
You can, and on a brand-new domain with a single sending system it is reasonable. On an established domain it is risky: you will discover your unauthorised senders by having their mail rejected, and some of them will be systems your business depends on.
What is a realistic DMARC pass rate?
Once legitimate senders are authorised, well over 95% of your own mail should pass. The remainder is usually forwarding, which breaks SPF but should still pass on DKIM. If a large share is failing both, you have a sender you have not accounted for.
Need This Set Up Properly?
Getting all three records right across every system that sends as your domain is fiddly, and the failure mode is silent. BIGBANG ITS FZE has supported UAE businesses since 2003, and our business email services include authentication configured and verified as part of the setup, not left as an exercise. If you already have mail elsewhere, our security services cover authentication review as a standalone piece of work.
Talk to our Dubai team and we will check what your domain publishes today.
