An email has two sender addresses. Your recipient only ever sees one of them, and SPF only ever checks the other one. Almost everything businesses get wrong about email deliverability follows from not knowing that.
This article covers the technical layer: the three DNS records, what the mailbox providers now demand, and how to turn on enforcement without silently blocking your own invoices. Campaign strategy, list building and retainers are covered separately in our email marketing guide.
Why is my business email going to spam?
Usually because your domain fails an authentication check that mailbox providers now enforce rather than merely prefer. Google, Yahoo and Microsoft have each published sender requirements within the last two years, and mail that does not meet them is filtered or refused no matter how legitimate it is.
The second reason is reputation, meaning your bounce and complaint history. Those are separate problems with separate fixes, and diagnosing which one you have is the first useful step.
The two From addresses
Every message carries an envelope sender, used behind the scenes for bounce handling and never displayed, and a header From address, which is the only one a human sees. They are defined in different standards and nothing requires them to match.
Microsoft's own documentation walks through the consequence with a worked example [5]. An attacker registers their own domain, publishes a valid SPF record for it, and sends mail with their domain in the envelope but your company's name and address in the visible From. SPF passes cleanly, because their server genuinely was authorised to send for their domain. The recipient sees your bank, your finance team, your brand.
Microsoft states the limitation directly, noting that SPF validates sources for the envelope domain only and does not consider the domain in the From address or the alignment between them [5].
What SPF does, and what it does not
SPF publishes a DNS record listing which servers may send using your domain, and it is defined in RFC 7208 [1]. It checks the envelope sender and the server greeting, not the visible From.
The RFC is unusually candid about its own limits. It has a section titled to the effect that SPF-authorised email may contain other false identities, and states that a message which passes an SPF check may still contain false identities in the visible message header fields [1]. That is the standard itself telling you not to rely on SPF for the thing most businesses rely on it for.
SPF also breaks on forwarding. Forwarding rewrites the envelope sender, so the forwarding server is not on your list and the check fails for that copy. This is normal rather than a misconfiguration, and it is the practical reason to have DKIM as well.
What DKIM does, and what it does not
DKIM signs parts of your outgoing message with a private key and publishes the public key in DNS under a selector, so a receiver can confirm nothing was altered in transit. It is defined in RFC 6376 [2].
Its limit is the same shape as SPF's. The standard states that the signing identity is not required to match an address in any particular header field [2], which includes the visible From. A message can carry a valid signature from a domain unrelated to the company displayed in the inbox. DKIM proves integrity and origin of signing. It does not, alone, tell you the sender is who they appear to be.
DKIM also breaks when a message is modified in flight, which mailing list footers and some security gateways do routinely.
What DMARC adds
DMARC requires that whichever check passed belongs to the same domain as the visible From address, and lets you publish what receivers should do when that fails. It was specified in RFC 7489 [3] and is the mechanism that closes the gap the other two leave open.
The rule is more forgiving than people expect. A message passes DMARC if SPF passes with alignment or DKIM passes with alignment. It fails only when both fail [9]. Since SPF tends to break on forwarding and DKIM tends to survive it, having both configured gives you two independent routes to a pass.
There are three policies. Monitoring asks receivers to take no action and simply report. Quarantine asks them to treat failures as suspicious, typically routing to junk. Reject asks them not to accept the message at all, meaning no delivery anywhere, not even a spam folder [3].
One update worth noting for accuracy rather than action. In May 2026 the IETF published documents moving DMARC onto the standards track and replacing the 2015 specification, adjusting some tags and changing how the organisational domain is determined [4]. Record syntax still starts the same way, so existing records remain valid, and when we checked in August 2026 the major providers' own guidance still described the earlier mechanism.
What Gmail, Yahoo and Outlook now require
These stopped being recommendations. Google's requirements took effect on 1 February 2024, with the unsubscribe element following on 1 June 2024 [6]. Microsoft's took effect on 5 May 2025 [8]. Yahoo began enforcing in February 2024 [7].
| Yahoo | Microsoft | ||
|---|---|---|---|
| Bulk threshold | 5,000 a day to Gmail | Not stated numerically on its own page | 5,000 a day to Outlook, Hotmail, Live, MSN |
| SPF and DKIM | Both, for bulk | Both, for bulk | Required |
| DMARC record | Required, monitoring accepted | Required, monitoring accepted | Required |
| Alignment | Required | Required | Required |
| Spam or complaint rate | Below 0.30 per cent | Below 0.3 per cent | Not published numerically in what we could read |
| One-click unsubscribe | Marketing mail, honoured in 48 hours | Bulk mail, honoured in 2 days | Required for bulk |
Two details are worth pulling out. Google accepts a monitoring-only DMARC policy [6], so you can satisfy the requirement immediately with a record that changes nothing about delivery. And Microsoft's stance is the firmest of the three: its own postmaster material describes starting with junk folder routing and then moving to rejecting messages until the DNS records are corrected [8].
Note also what is not exempt. The authentication rules apply per sending domain regardless of message type, so your invoicing system is in scope. The one-click unsubscribe requirement, standardised in RFC 8058 [13], is scoped by both Google and Yahoo to marketing and subscribed mail [6][7]. An invoice needs authenticating but does not need an unsubscribe link.
How to turn DMARC on without breaking your own mail
Go monitoring, then quarantine, then reject, and do not skip a step. AWS states the reason plainly in its own guidance: using the wrong policy at the wrong time can cause your email not to be delivered [9].
Stage one, monitoring. Publish a DMARC record asking for reports and no action. Nothing about your delivery changes. The purpose, in AWS's words, is to learn which emails will be affected and to get third-party and authorised senders into alignment first [9].
Stage two, quarantine. Once your reports account for your legitimate traffic, move to quarantine so failures go to junk rather than being refused. This is a reversible mistake if you have missed something.
Stage three, reject. Only after the first two. Now failures are refused at the SMTP level.
The reason the order matters is that almost no business has one system sending its mail. A typical UAE company sends invoices from accounting software, quotes from a CRM, campaigns from a marketing platform, and everyday mail from staff mailboxes. Some of those were connected years ago and were never authenticated. Publish reject before checking, and those systems stop delivering outright, with no junk folder fallback and no notification to you. The business simply stops sending from that source and finds out when a client asks why nobody replied.
Reading the reports, and finding your shadow senders
Aggregate reports are the point of the monitoring stage. Participating receivers send a machine-readable summary, typically daily, to an address you nominate, listing each source that sent mail claiming to be your domain, whether it passed authentication and alignment, and what was done with it [3].
This is how you find shadow senders. Nearly every established business has at least one: an old newsletter tool still billing a card, a supplier's platform sending on your behalf, a recruitment system, or an account somebody has compromised. Until DMARC reporting runs, none of them are visible.
The reports arrive as XML and are not comfortable to read raw. Parsing them is a solved problem with commercial tools, and we are not recommending one here.
One misconfiguration worth naming because it is invisible. On Amazon SES, the default envelope domain is Amazon's own, which means SPF passes but does not align with your domain. DKIM signing with your domain still carries the DMARC pass, so mail keeps working and nothing looks wrong, but you are relying on one leg instead of two. Configuring a custom sending domain restores SPF alignment [11].
Reputation, in actual numbers
Most guidance on reputation is vague. Amazon SES publishes exact thresholds, which are worth knowing even if you send elsewhere, because they show what the industry treats as acceptable [10].
On bounces, SES advises staying below 2 per cent, places an account under review at 5 per cent or above, and may pause sending at 10 per cent or above. Only hard bounces to unverified domains count [10].
On complaints, SES advises below 0.1 per cent, reviews at 0.1 per cent or above, and may pause sending at 0.5 per cent or above [10].
Compare those with the 0.30 per cent spam rate Google and Yahoo publish [6][7] and something useful falls out: the complaint threshold your own sending platform applies can be stricter than the one the mailbox provider applies. A sender comfortably inside Gmail's rule can still be on course to have their account paused.
The behaviours that keep those numbers down are unglamorous. Send only to people who asked. Use a confirmed opt-in. Remove hard bounces immediately and permanently. Treat a re-engagement send to a list you have not mailed in a year as the highest-risk thing you will do all quarter, and send it in small batches rather than as one blast.
A pattern we see. A UAE business decides to fix spoofing, reads that DMARC is the answer, and publishes a reject policy the same afternoon. Nothing appears to happen for two days, because their staff mail is on a properly configured platform. Then the finance team notices no client has acknowledged an invoice all week. The invoicing system had been sending unauthenticated for three years, and reject turned a silent misconfiguration into a silent outage.
Domain reputation, subdomains and dedicated IPs
Reputation increasingly attaches to your authenticated domain rather than to a sending IP address, which is good news because a domain reputation travels with you if you change platform.
That makes the subdomain decision worth taking early. Sending campaigns from a subdomain rather than your root domain means a complaint spike on a marketing send damages campaign deliverability rather than your ability to bill clients. It is a cheap structural choice that is awkward to retrofit.
A dedicated IP is rarely the right first purchase at SME volume. It only helps once your sending is high and consistent enough to keep the address warm, and a low-volume unwarmed dedicated IP typically performs worse than a well-managed shared pool. Fix authentication and list hygiene before spending here.
If you send from a free consumer mailbox domain, none of this is available to you. Authentication records are published in DNS for a domain you control, and you do not control gmail.com. That is a structural fact rather than a rule anyone published, and it is the strongest argument for using your own domain for anything resembling a business document.
Does UAE law say anything?
Less specifically than you might hope, and we would rather be precise than impressive. The telecom regulator published a regulatory policy on unsolicited electronic communications in 2009 whose definitions do include electronic mail addresses [14]. However, its operative obligations are written for licensed telecom operators, and the only detailed implementing annex we found, covering consent windows, quiet hours and record keeping, is scoped to mobile text messages rather than email.
So we are not going to present SMS rules as email rules. The obligation that actually governs using someone's address for marketing is the general consent principle in the UAE data protection law, which prohibits processing personal data without the owner's consent subject to defined exceptions [15]. That is the same position our email marketing guide already takes, and nothing here changes it.
What it costs
The records themselves are free DNS configuration, which is exactly how our cybersecurity guide describes them. What costs money is finding every system sending under your domain and getting each one aligned. A focused authentication setup and remediation starts from around AED 1,500 with us, covering SPF, DKIM, DMARC, alignment across your sending systems, and any custom sending domain configuration. Ongoing DMARC monitoring and reporting starts from around AED 500 a month. These are our own figures rather than a market survey, since no regulator or standards body publishes rates for this work. Final pricing depends mostly on how many separate systems send mail under your domain.
Worth knowing for contrast: the sending infrastructure itself is close to free. Amazon SES publishes outbound sending from 0.10 US dollars per thousand emails with no minimum commitment, and a managed dedicated IP at 15 US dollars a month, checked in August 2026 [12]. When deliverability goes wrong, you are almost never paying for the wrong platform. You are paying for nobody having configured the DNS.
Where to start this week
- Check whether you have SPF, DKIM and DMARC records at all, for every domain you send from
- Publish a DMARC record at monitoring with a reporting address, which changes nothing and starts the clock
- List every system that sends mail as you: accounting, CRM, marketing, helpdesk, recruitment, e-commerce
- Read a fortnight of aggregate reports and find the senders that are not on your list
- Fix alignment on each legitimate sender, then move to quarantine, then to reject
- Move bulk campaigns onto a subdomain before you have a reputation problem, not after
- Remove hard bounces permanently and stop sending to anyone who did not ask
If your invoices are landing in junk and nobody can tell you why, contact us and we will start by reading what your domain is actually publishing.
References
[1] IETF, RFC 7208: Sender Policy Framework (SPF). datatracker.ietf.org
[2] IETF, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. datatracker.ietf.org
[3] IETF, RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC). datatracker.ietf.org
[4] IETF, RFC 9989, RFC 9990 and RFC 9991: updated DMARC specification, May 2026. datatracker.ietf.org
[5] Microsoft, How email authentication works in Microsoft 365. learn.microsoft.com
[6] Google Workspace Admin Help, Email sender guidelines. support.google.com
[7] Yahoo Sender Hub, Best practices. senders.yahooinc.com
[8] Microsoft, Outlook.com postmaster and sender requirements. sendersupport.olc.protection.outlook.com
[9] Amazon Web Services, Complying with DMARC using Amazon SES. docs.aws.amazon.com
[10] Amazon Web Services, Amazon SES sending review process FAQs. docs.aws.amazon.com
[11] Amazon Web Services, Using a custom MAIL FROM domain. docs.aws.amazon.com
[12] Amazon Web Services, Amazon SES pricing. aws.amazon.com
[13] IETF, RFC 8058: Signaling One-Click Functionality for List Email Headers. datatracker.ietf.org
[14] TDRA, Regulatory Policy: Unsolicited Electronic Communications. tdra.gov.ae
[15] The Official Portal of the UAE Government, Data protection laws. u.ae
