DMARC, DKIM, and SPF Email Authentication Implementation
DMARC, DKIM, and SPF Email Authentication Implementation is a fixed-fee, per-domain engagement that gets every service sending mail as your domain — Microsoft 365 plus your marketing platforms, CRM, helpdesk, and billing systems — properly authenticated, then walks DMARC from monitoring (p=none) to enforcement (quarantine or reject) over a monitored four-week ramp, reading aggregate reports at each step so legitimate mail never gets blocked by your own policy. This is what Google and Yahoo have required of bulk senders since February 2024, and what Microsoft now enforces for high-volume senders to Outlook consumer mailboxes: unauthenticated mail is rejected outright, not just filtered to junk.
What this engagement is
Email authentication stopped being optional in two steps. In February 2024, Google and Yahoo began requiring bulk senders to publish SPF, DKIM, and at least a p=none DMARC policy — unauthenticated bulk mail to Gmail and Yahoo mailboxes now fails. In May 2025, Microsoft followed for its consumer mailboxes: high-volume senders (over 5,000 messages a day) to Outlook.com, Hotmail, and Live addresses must pass SPF, DKIM, and DMARC, and non-compliant mail is rejected with error 550 5.7.15 — it does not land in junk; it does not land at all. Meanwhile a domain without DMARC enforcement remains free to spoof, which is how attackers send 'your' invoices to your customers. The hard part is not publishing three DNS records — it is doing so without breaking your own mail. Most organizations discover during this engagement that more services send as their domain than anyone had listed: the marketing platform, the CRM, the helpdesk, the billing system, a scanner in the office, a line-of-business app on a developer's SMTP key. This engagement starts with that inventory, from your knowledge and from DMARC aggregate-report data. Then, per domain: an SPF record that authorizes every legitimate source and stays under the 10-DNS-lookup limit (flattened where necessary), DKIM signing enabled and verified for Microsoft 365 and for each approved third-party sender, and a DMARC record with aggregate reporting. Enforcement is a ramp, not a switch: p=none while the reports confirm every legitimate source aligns, then quarantine, then reject where the data supports it — over roughly four monitored weeks. Domains that send no mail at all get locked down too, because parked domains are the ones attackers like best. Who this is for: any organization sending email as its own domain — and urgently, anyone whose marketing or transactional mail is already bouncing off Gmail, Yahoo, or Outlook consumer addresses. This engagement covers outbound authentication: proving your mail is yours. Inbound filtering — protecting your users from other people's spoofed mail — is the separate Additional Spam and Phishing Protection and Microsoft Defender for Office 365 Implementation work. Pricing is fixed: $450 per domain plus a $950 tenant fee, quoted in writing before work begins. The four weeks are a monitored calendar ramp — DNS changes propagate and report data accumulates on their own schedule — not four weeks of continuous engineering.
Success criteria
What you receive
How the work unfolds
Kickoff and sending-service inventory per domain. Design and publish the SPF records within the lookup limit, enable DKIM for Microsoft 365 custom domains, and begin DKIM enablement with each approved third-party sender — some require ticket cycles with their support teams, which is why this starts on day one.
Publish DMARC records at p=none with aggregate reporting to the agreed destination. Verify reports are flowing, complete outstanding third-party DKIM work, and take the first report reading: every legitimate source must show as aligned before anything is tightened.
Read a full week of aggregate data per domain. Fix stragglers — sources missing from SPF, services signing with the wrong domain, forwarding patterns — and, where the data is clean, step policy to quarantine. Sources that remain unknown are investigated rather than assumed.
Confirm quarantine caused no legitimate-mail loss, then step to the agreed final policy — reject where the data supports it. Lock down parked domains, finalize the as-built and runbook, and hand off: what was published, why, and how to change it safely.
Prerequisites
Who does what
IT Partner
- Lead the assessment, sending-service inventory, and per-domain authentication design.
- Design and publish (or hand to your DNS person, ready to paste) the SPF, DKIM, and DMARC records for each in-scope domain, keeping SPF within the 10-DNS-lookup limit.
- Enable and verify DKIM for Microsoft 365 custom domains, and configure or coordinate DKIM with each approved third-party sending service.
- Collect and read DMARC aggregate reports weekly during the ramp, and document findings before every policy step.
- Execute the staged enforcement ramp per domain, stepping policy only when report data shows legitimate sources aligned.
- Lock down approved parked and non-sending domains.
- Troubleshoot authentication failures for in-scope sources discovered during the ramp, and document any source that cannot be made to align with the agreed handling.
- Deliver the as-built documentation and the add-a-sender runbook, and conduct the handoff.
Your team
- Provide DNS access or apply requested DNS changes within one business day.
- Provide access to Microsoft 365 and to third-party sending services, or connect us with the internal owner of each.
- Approve the sending-service inventory — including retiring senders you no longer want authorized to use your domain.
- Provide and maintain subscriptions for third-party services, including any optional paid DMARC analytics product.
- Approve each enforcement step within the weekly cadence, and decide the final policy (quarantine or reject) per domain.
- Own relationships with third-party vendors whose platforms limit or delay DKIM support, using the findings we document.
- Notify us of new sending services introduced during the engagement so records stay accurate.
- Review deliverables and approve acceptance against the published success criteria; operate the runbook after handoff.
What's not included
Limitations & technical notes
Frequently asked questions
Why is this suddenly mandatory? Email worked fine for years.
Because the big mailbox providers stopped asking politely. Since February 2024, Google and Yahoo require bulk senders to publish SPF, DKIM, and at least a monitoring-mode DMARC record. Since May 5, 2025, Microsoft enforces the same for high-volume senders (5,000+ messages a day) to Outlook.com, Hotmail, and Live mailboxes — and Microsoft rejects non-compliant mail outright with error 550 5.7.15 rather than junk-foldering it. Even below those volume thresholds, unauthenticated mail is scored increasingly harshly, and a domain without DMARC enforcement can be spoofed by anyone.
What do SPF, DKIM, and DMARC each actually do?
SPF is a DNS record listing which servers may send mail as your domain — receivers check the connecting server against it. DKIM is a cryptographic signature your sending services add to each message, proving it came from an authorized source and was not altered. DMARC ties them together: it requires that at least one of SPF or DKIM passes and aligns with the visible From address, tells receivers what to do when neither does (nothing, quarantine, or reject), and sends you aggregate reports showing who is sending as your domain — including the senders you did not know about.
Will implementing this break our email?
Done carelessly, yes — that is the main reason to do it as a monitored ramp. DMARC starts at p=none, which changes nothing about delivery and only collects data. We tighten to quarantine, and then reject, only after aggregate reports prove every legitimate sending service passes alignment. If reports show an unknown source, the ramp pauses for that domain while we investigate. Nothing in this engagement blocks mail on a hunch.
Doesn't Microsoft 365 already handle this for us?
Partially, and that partial coverage is what catches people. Microsoft 365 signs your mail with DKIM automatically only for the default onmicrosoft.com domain; DKIM for your custom domains must be enabled deliberately, with CNAME records published in your DNS. SPF for Microsoft 365 is one include — but every other service sending as your domain needs its own authorization, and Microsoft publishes no DMARC record for you at all. A tenant that has 'always worked' typically has SPF only, which satisfies neither Google's nor Microsoft's current requirements for bulk senders.
How is this different from your Additional Spam and Phishing Protection service?
Direction. Additional Spam and Phishing Protection is an inbound quick fix: it hardens what arrives in your users' mailboxes, and touches your own records only as far as Microsoft 365 needs. This engagement is the outbound authentication program: every sending service — marketing platform, CRM, helpdesk, billing — inventoried and authenticated across every domain, with DMARC walked to enforcement on report evidence and parked domains locked down. Many organizations need both; they solve different problems.
What is SPF flattening, and will we need it?
SPF allows at most 10 DNS lookups per check; exceed the limit and receivers treat the record as permanently erroring, which quietly fails authentication for everything. Each third-party include typically costs one or more lookups, so an organization with a marketing platform, CRM, helpdesk, and a few apps can blow past 10 without noticing. Flattening replaces lookup-consuming includes with resolved addresses, or restructures senders onto subdomains. We count your lookups in week one; whether you need flattening depends on how many services send as each domain — and flattened records are one of the things the handoff runbook teaches your team to maintain.
Our marketing platform sends 50,000 emails a week. Is that why Gmail is blocking us?
Very likely — you are exactly who the bulk-sender rules target. At that volume Google expects SPF, DKIM alignment from the platform, a DMARC record, low spam-complaint rates, and one-click unsubscribe. This engagement fixes the authentication half: the platform gets DKIM signing as your domain, SPF authorization, and DMARC alignment verified in the aggregate reports before enforcement. Spam-complaint rates, list quality, and unsubscribe mechanics live inside your marketing platform and are yours to manage — we will tell you plainly if the reports suggest the problem is reputation rather than authentication.
What about domains we own but never send from?
They are the easiest win in the whole engagement. A parked domain with no SPF or DMARC record is an open invitation — attackers deliberately spoof the domains nobody watches. Every approved non-sending domain gets a deny-all SPF record (v=spf1 -all) and a p=reject DMARC policy, telling every receiver on the internet to refuse mail claiming to be from it. It is a few DNS records per domain and permanently closes a door.
What happens when we reach p=reject — are we done?
You are done ramping; you are not done watching. New sending services get added by well-meaning teams, vendors change their infrastructure, and each change can silently fail alignment until someone reads the reports. The handoff runbook gives your administrators the procedure for adding a sender safely, and ongoing DMARC monitoring — someone reading your aggregate reports month over month and flagging anomalies — is available as a separately quoted subscription if you would rather not carry that discipline in-house.
Do we need a paid DMARC reporting tool?
Not for this engagement — we collect and read the aggregate reports during the ramp regardless of tooling, and reports can flow to a mailbox you control. A paid analytics product makes long-term monitoring materially more pleasant (raw aggregate reports are XML files nobody enjoys), so if you plan to watch the reports yourself after handoff, we will recommend options; the subscription cost is yours and the choice does not change the engagement price.
What is MTA-STS, and should we add it?
MTA-STS tells sending servers that your domain's mail must be delivered over verified TLS, closing off downgrade and interception tricks; TLS-RPT sends you reports about delivery-encryption failures. Neither is required by the Google, Yahoo, or Microsoft sender rules, which is why they are an optional add-on here rather than core scope. If your industry handles sensitive correspondence, they are worth the modest extra effort — ask during the engagement and we will quote them separately.
How long does this take, and why four weeks?
About four calendar weeks per batch of domains, and the pacing is evidence, not effort: DNS changes propagate, third-party DKIM tickets take vendor time, and each enforcement step should sit on at least a week of clean aggregate-report data before the next. The active engineering happens in focused sessions inside that window. Client-side DNS turnaround is the most common thing that stretches the schedule — which is why applying changes within one business day is a listed prerequisite.