Skip to content
Cybersecurity

SPF, DKIM and DMARC in Morocco: protecting your company’s email domain against spoofing

SPF, DKIM and DMARC explained simply: what each one does, DNS records for Microsoft 365 and Google Workspace, a gradual move to reject, mistakes to avoid.

By the ALLSAFE SOLUTIONS engineering team24 October 20269 min read
Secured server room

The short answer: SPF, DKIM and DMARC are three DNS records that let mail servers around the world check that an email carrying your domain name really comes from you. SPF lists the servers allowed to send, DKIM signs each message with a key, and DMARC checks that the address the recipient sees matches one of the two, then says what to do on failure: nothing, send to junk, or reject. Until DMARC is set to reject, anyone can still send a fake email “from” your finance department to your customers.

This guide explains what each one does, the values to publish for Microsoft 365 and Google Workspace, how to reach reject without blocking your own emails, and the mistakes we fix most often at Moroccan companies. Technical details come from Microsoft’s and Google’s official documentation and from IETF standards.

Why it has become essential

Domain spoofing is the basis of the most expensive scams an SMB faces: a fake supplier bank detail change, a fake urgent request from the CEO, a fake invoice. We describe these scenarios in the 8 email scams targeting Moroccan SMBs. Without DMARC set to reject, your customer’s mail server has no clear instruction to discard a message claiming to come from your domain.

The second issue is deliverability. In its sender guidelines, Google requires at least SPF or DKIM from every sender to Gmail, and all three mechanisms from those sending more than 5,000 messages a day to Gmail accounts. Microsoft applies comparable requirements to domains above that volume towards Outlook.com. Even below those thresholds, a poorly authenticated domain sees its quotes and invoices land in junk more often.

SPF, DKIM and DMARC in one table

Mechanism What it checks Where it is published Limit to know
SPF The sending server is on the allowed list of the envelope domain (MAIL FROM) A TXT record on the domain Does not protect the visible address, often fails on forwarding, maximum 10 DNS lookups
DKIM The message carries a valid signature and was not altered A TXT or CNAME on selector._domainkey Every sending service must sign with your domain
DMARC SPF or DKIM passes and matches the domain of the visible address (From) A TXT on _dmarc.yourdomain Without a quarantine or reject policy, it only observes

The key concept is alignment. A message can pass SPF for a sending provider’s technical domain while showing your address in the “From” field. Only DMARC links authentication to the address the recipient sees. A message passes DMARC if at least one of the two checks, SPF or DKIM, passes and is aligned.

SPF: declaring who may send

An SPF record is a TXT line that starts with v=spf1, lists the authorised sources and ends with a rule for everything else. For a domain that only sends through Microsoft 365, Microsoft recommends:

v=spf1 include:spf.protection.outlook.com -all

For Google Workspace, the source to include is include:_spf.google.com. If an internal server also sends, add its public IP address with ip4:.

Three rules prevent most outages:

  • One SPF record per domain. Two v=spf1 lines cause a permanent error, and SPF fails for all your email.
  • No more than 10 DNS lookups. Each include:, a, mx, exists or redirect uses at least one, and nested include: entries add more. Beyond that, SPF fails. ip4: and ip6: addresses do not count.
  • End with -all. Microsoft recommends it once DKIM and DMARC are in place, because DMARC can then act properly on unauthorised messages. Keep ?all for testing.

DKIM: signing every message

DKIM adds an encrypted signature to every email, verifiable with a public key published in your DNS. It proves the message comes from a service authorised by your domain and was not altered on the way. Unlike SPF, it usually survives forwarding.

With Microsoft 365, DKIM is enabled for each custom domain in the Microsoft Defender portal, under email authentication settings. Microsoft provides two CNAMEs to publish, selector1._domainkey and selector2._domainkey, whose values are specific to your tenant: copy them from the portal, never from an example. Once the CNAMEs are in place, turn signing on; the second selector is used for key rotation.

With Google Workspace, the key is generated in the Admin console (Apps, Google Workspace, Gmail, Authenticate email). Google recommends a 2,048-bit key if your DNS host supports it, with the google prefix, giving the host google._domainkey. Publish the TXT value, then click “Start authentication”. Google says it can take up to 48 hours before signing takes effect.

An often forgotten point: every tool that sends with your domain (email marketing platform, CRM, ERP such as Odoo, invoicing platform, website) must also sign with DKIM using your domain. Otherwise, its messages may pass SPF for the provider’s domain but fail DMARC.

DMARC: tying it together and giving the instruction

DMARC is published as a TXT record on the _dmarc host. Its minimal starting form:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.ma

Tag Role Values
p Policy for the domain none (monitor), quarantine (junk), reject
rua Address for daily aggregate reports A dedicated mailbox, not an employee’s
pct Share of failing messages the policy applies to All by default; useful for stepping up
sp Policy for subdomains Same values as p
adkim / aspf Relaxed or strict alignment r (default) or s

rua reports arrive as XML files sent by the major mailbox providers. They list the IP addresses sending on behalf of your domain, and whether they pass. Raw, they are hard to read: a DMARC reporting service turns them into a dashboard. Reading them is how you discover the multifunction printer, the payroll software or the old web host that was still sending “as you”.

A DMARC record on the main domain also covers every subdomain without its own record, including subdomains that do not exist. However, each subdomain that actually sends needs its own SPF and DKIM.

How to reach reject without breaking anything

Microsoft explicitly recommends a gradual approach. Here is the one we follow:

  1. List every sender: mailbox platform (Microsoft 365, Google Workspace, old cPanel), website and forms, ERP and CRM, email marketing tool, payroll software, scanners and printers, monitoring alerts.
  2. Fix SPF: one record, under 10 lookups, ending with -all.
  3. Enable DKIM on the mailbox platform and on every third-party service that supports it, with your domain.
  4. Publish DMARC at p=none with a dedicated reporting address.
  5. Read the reports for several weeks and fix every legitimate source that fails, or move it to a dedicated subdomain.
  6. Move to p=quarantine, in steps with pct if needed, then monitor.
  7. Move to p=reject once the reports are clean, and keep monitoring them.

Microsoft also advises sending marketing email from a subdomain (for example news.yourdomain.ma), with its own SPF, DKIM and DMARC. A poorly received campaign then does not damage the reputation of the domain your teams use every day.

What about domains that send nothing?

Many companies own several domains: the .com version of a .ma, a former brand, a domain reserved for a project. If they send no email, they are even easier to spoof, because nobody watches them. Microsoft’s recommended setup is short:

Record Host Value
SPF domain v=spf1 -all
DMARC _dmarc v=DMARC1; p=reject;

No DKIM on those domains. If you are on Microsoft 365 and do not send from the onmicrosoft.com domain, Microsoft recommends adding a reject DMARC record to it as well, from the admin center.

The mistakes we fix most often

  1. Two SPF records after a migration, the old host’s and the new one: SPF fails for the whole domain.
  2. An SPF record over 10 lookups after adding an include: for every new tool.
  3. DKIM never enabled after moving to Microsoft 365 or Google Workspace: mail works, but nothing is signed with your domain. We cover this in our guide to migrating email from cPanel to Microsoft 365.
  4. DMARC at p=none for years, with nobody reading the reports: spoofing is observed but never blocked.
  5. Reports sent to the CEO’s mailbox or to a former employee, instead of a dedicated mailbox or group.
  6. A straight jump to reject that makes ERP invoices or website emails disappear.
  7. Forgotten unused domains, which are exactly what fraudsters use.

What SPF, DKIM and DMARC do not do

These three mechanisms protect your domain against exact spoofing. They do not stop a fraudster from buying a lookalike domain one letter away from yours, or from compromising a real mailbox at your company or at a supplier. They therefore go together with MFA on every account, see our MFA rollout guide, inbound email filtering, and a procedure to confirm any bank detail change by phone. For a Microsoft 365 tenant, these settings are part of the 10 settings to secure Microsoft 365.

SPF, DKIM and DMARC checklist

  • Complete list of the services sending with your domain.
  • One SPF record, under 10 DNS lookups, ending with -all.
  • DKIM active on the mailbox platform and every third-party service.
  • DMARC published, with a dedicated reporting mailbox and a tool to read the reports.
  • A schedule to move from none to quarantine, then reject.
  • A dedicated subdomain for marketing email.
  • SPF and DMARC set to reject on domains that send nothing.
  • A check after every new tool or change of provider.

How we work

We start with a review of your domains: current records, detected senders, real email headers. We fix SPF, enable DKIM on your mailbox platform and tools, publish DMARC in monitoring mode, then read the reports with you until you reach reject. The work is done in your DNS zone, whoever hosts your domain, and is part of our business cybersecurity services in Morocco. For the mailbox platform itself, we work as a Microsoft partner and Google Workspace partner, within our managed Microsoft 365 cloud offer. We work from Casablanca, remotely or on site anywhere in Morocco.

For mail on Google, these settings are part of our guide to Google Workspace in Morocco.

Want to know whether your domain can be spoofed today? Request your free initial audit: we check SPF, DKIM and DMARC on your domains and reply within 24 business hours with the fixes to make.

Frequently asked questions

SPF, DKIM and DMARC: do we really need all three?

Yes. SPF alone does not protect the address the recipient sees, and it often fails when a message is forwarded. DKIM survives forwarding better but does not say what to do on failure. DMARC ties both to the visible address and gives the receiving server its instruction. Google and Microsoft require all three for domains that send high volumes.

Can we go straight to DMARC reject?

It is not advisable, and Microsoft says so too. A forgotten payroll application, website or printer would see its emails rejected. Start with p=none and a reporting address, fix every legitimate sender that fails, then move to quarantine, in steps with pct if needed, and finally to reject.

Where are these records configured for a .ma domain?

At the domain’s DNS host, often the registrar or the web host, not in Microsoft 365 or Google Workspace. Those services provide the values to publish (SPF include, DKIM keys or CNAMEs), but the records are added in the DNS zone. The principle is the same for a .ma, a .com or any other domain.

What about our domains that never send email?

Protect them too, because they are easy to spoof. For an unused domain, Microsoft recommends an SPF of “v=spf1 -all” and a DMARC of “v=DMARC1; p=reject;”, with no DKIM record. It takes a few minutes and closes a door that is often left open.

How do I know whether my domain is already protected?

Query the TXT records of your domain and of _dmarc.yourdomain with a DNS lookup tool, or look at the Authentication-Results header of an email you sent to a Gmail or Outlook mailbox: it shows spf=, dkim= and dmarc=. We run this check as part of the free initial audit.

About the editorial team

ALLSAFE SOLUTIONS

Network, security and cloud engineers

Written by the engineering team at ALLSAFE SOLUTIONS, a managed IT provider founded in Casablanca by network, security and cloud engineers. Our articles draw on the projects we deliver for clients in Morocco and abroad.

LinkedIn

This guide is part of our expertise in business cybersecurity in Morocco: free initial audit, reply within one business day.

← All articles
CallWhatsAppFree audit