When a business tells us its newsletter has stopped working, the first thing we check is not the subject line. It is the DNS. A surprising share of the email marketing problems we are asked to fix in the UAE turn out to be authentication problems: the campaign was well written, the list was fine, and the receiving mailbox simply did not believe the message came from who it said it came from.
This is the practical version: what each record does, the order to set them up in, and the specific mistakes we find when a domain already sends normal mail through Microsoft 365 or Google Workspace and then adds a marketing platform on top.
What each record actually does
| Record | The question it answers | Where it lives |
|---|---|---|
| SPF | Is this server allowed to send mail for this domain? | One TXT record on the domain itself |
| DKIM | Was this message signed by the domain, and unchanged since? | A public key per sending service, under a selector._domainkey name |
| DMARC | Do SPF or DKIM pass for the domain in the From address, and if not, what should happen? | One TXT record at _dmarc on the domain |
None of the three is enough on its own. SPF checks the envelope sender, which the reader never sees. DKIM proves a signature, but not that the signing domain is yours. DMARC is the record that ties both back to the address in the From line, which is the one your customer reads and the one spammers forge.
Why marketing email goes to spam when normal email does not
Your day-to-day mail from Outlook or Gmail usually arrives fine, because Microsoft and Google set up authentication for their own sending when the domain was connected. The trouble starts when a second service begins sending as the same domain: a newsletter platform, a CRM sending sequences, a booking system sending confirmations. Each of those is a new server claiming to be you, and unless the DNS says it is allowed, mailbox providers have every reason to doubt it.
- The platform was never added to SPF, so its servers are not on the list of allowed senders.
- DKIM was left on the platform's shared default, so messages are signed by the platform's domain rather than yours.
- There is no DMARC record at all, which a growing number of mailbox providers treat as a reason for suspicion on bulk mail.
- The list itself has gone stale, so a burst of bounces and spam complaints damages the domain's reputation regardless of authentication.
Step 1: one SPF record, merged, not duplicated
SPF is a single TXT record that lists every service allowed to send for the domain. The most common mistake we see is a second SPF record added for the marketing platform, because the platform's setup screen said to add one. Two SPF records on the same domain is an error, and receiving servers treat it as a failure for all of your mail, not just the newsletter.
- 1Look up the domain's existing TXT records and find the one starting with v=spf1.
- 2Add the new platform's include to that same record, alongside the Microsoft 365 or Google Workspace include that is already there.
- 3Keep the record under SPF's limit of ten DNS lookups. Every include costs at least one, and nested includes count too. A domain with six connected tools can break this limit without anyone noticing.
- 4End the record with ~all (soft fail) while you are setting up, and only move to -all once you know every legitimate sender is listed.
If the lookup limit is a problem, the cleanest fix is usually to send marketing from a subdomain, such as news.yourdomain.ae, with its own SPF record. That also keeps campaign reputation separate from the domain your sales team uses for one-to-one mail, which is worth doing for its own sake.
Step 2: DKIM on your domain, for every sender
Every serious email platform supports custom DKIM: it gives you one or two records, usually CNAMEs, to publish under your own domain, and from then on it signs messages as you. Until you do this, many platforms sign with their own shared domain, which passes DKIM but does nothing for yours.
- Each sending service gets its own selector, so Microsoft 365, your email platform and your CRM can all sign independently without clashing.
- Publish the records, then press the verify button in the platform. Several platforms will not switch to your domain's signature until verification succeeds.
- Send a test to a Gmail address and open the original message. The authentication results should show DKIM passing with your domain, not the platform's.
Step 3: DMARC, starting at none
DMARC tells receiving servers what to do when a message claiming to be from your domain fails authentication, and where to send reports about it. Its policy has three settings, and the order you move through them matters.
| Policy | What happens to failing mail | When to use it |
|---|---|---|
| p=none | Delivered as normal; you receive reports | First, while you find every service sending as your domain |
| p=quarantine | Usually sent to spam | Once reports show your legitimate senders all pass |
| p=reject | Refused outright | Once quarantine has run cleanly for a while |
The reports are the point of starting at none. Within a few days they show every server sending as your domain, and almost every business finds one it forgot: the accounting system that emails invoices, the website contact form, a supplier portal, a booking tool. Moving to reject before those are fixed means your own invoices stop arriving, and nobody tells you, because the mail was refused rather than bounced back to a person.
Alignment: the check most setups fail
DMARC does not just ask whether SPF or DKIM passed. It asks whether they passed for the same domain that appears in the From address. That is alignment, and it is the step a platform's own setup checklist rarely explains.
A platform can show green ticks for SPF and DKIM while both checks are passing on the platform's own domain. Your campaign then fails DMARC on yours, because neither result is aligned with the address the customer sees. Custom DKIM on your domain fixes this for most setups, which is why Step 2 is not optional even when everything already looks green.
After authentication: what still decides the inbox
Authentication proves who you are. It does not make anyone want your email. Once the records are right, these decide whether messages keep reaching the inbox:
- List hygiene. Remove hard bounces immediately and suppress contacts who have not opened or clicked in a long time, before a mailbox provider decides for you.
- Consent. People who never asked to hear from you complain, and complaints are the signal mailbox providers weigh most heavily.
- Volume ramp. A new domain or subdomain should start with your most engaged contacts and build volume over a few weeks, rather than sending to the full list on day one.
- One-click unsubscribe. Make leaving easy. A contact who cannot find the unsubscribe link reaches for the spam button instead.
- Relevance. Segmented sends to people who expect them outperform the same message blasted to everyone, on every deliverability measure we track.
Common questions
Most often because the platform sending them is not properly authenticated for your domain: it is missing from SPF, signs with its own DKIM domain, or your domain has no DMARC record. After that, the usual causes are a stale list producing bounces and spam complaints, and sending large volumes from a domain with no sending history.
No. A domain must have exactly one SPF record. Adding a second, usually because a marketing platform's setup screen suggested it, causes SPF to fail for all mail from the domain. Merge the new platform's include into the existing record instead.
Start with p=none and a reporting address, then read the reports for a few weeks to find every service sending as your domain. Move to quarantine once your legitimate senders all pass, and to reject after that has run cleanly. Going straight to reject usually blocks something you forgot, such as invoices from an accounting system.
Usually, yes. Sending campaigns from a subdomain such as news.yourdomain.ae keeps their reputation separate from the domain your team uses for one-to-one mail, and gives the subdomain its own SPF record, which helps when the main record is near the ten-lookup limit.
No. They prove the email is genuinely from you, which is now required to be delivered at all by the largest mailbox providers. Whether it reaches the inbox after that depends on engagement, complaints, list hygiene and consent.