Email Authentication in Nigeria: The Records That Protect Your Domain from Fraud
If your business domain does not have a DMARC policy in place, anyone can send an email claiming to be from your domain right now. Receiving servers have no instructions to reject those messages.
Your clients, suppliers, or partners could receive a fraudulent email that appears to come from your organisation. You may have no visibility of it until someone contacts you, or until the damage is already done.
SPF, DKIM, and DMARC are the three DNS records that address this. They work as a system. Each one covers gaps the others leave open.
The Design Flaw at the Heart of Email
Email was not built for the world it now operates in. SMTP, the protocol that moves messages between servers, dates back to the early 1980s. It was designed for a small academic network where trust between participants was assumed. Sender verification was never included. Any server can still claim to be any domain, and nothing in the original protocol stops it.
SPF, DKIM, and DMARC were developed decades later as retrofitted fixes. According to Valimail’s 2026 State of DMARC Report, even among domains that have published a DMARC record, only 42 per cent have an enforcement policy in place. The majority are monitoring without acting.
SPF: Telling the Internet Which Servers Can Send on Your Behalf
How SPF Works
SPF (Sender Policy Framework) is a TXT record published in your domain’s DNS. It lists every mail server authorised to send on your behalf. When a receiving server gets a message claiming to be from your domain, it checks your SPF record. If the sending server is not on the approved list, the message fails SPF.
The check happens automatically at delivery, and what the server does with a failed result depends on your DMARC policy.
What an SPF Record Looks Like
An SPF record is a single line of text in your DNS. It carries a version identifier, lists every service authorised to send on your behalf, and ends with a default stance on anything not on that list. Every sending platform your domain uses needs its own entry. WordPress and WooCommerce sites using Zeptomail can find the full setup in ZeptoMail WordPress Integration.
You can only have one SPF record per domain. A second one causes both to be ignored entirely. This is a common mistake when businesses add a new sending service by creating a fresh record rather than updating the existing one.
SPF also has a limit of ten DNS lookups per evaluation. Businesses using multiple sending platforms can breach this limit and cause failures even with all the right services listed.
Hard Fail vs Soft Fail: A Decision, Not a Default
The ~all tag is a soft fail. It tells receiving servers to treat unlisted senders with suspicion but accept them anyway. The alternative, -all, is a hard fail: reject anything not on the list outright.
Most setup guides default to soft fail as the cautious option. The important distinction is that soft fail is not enforcement: it signals suspicion but cannot block anything. Some receivers factor it into spam scoring, but it provides no barrier to spoofing.
Hard fail (-all) is the correct end state, but it should only be applied once all legitimate sending sources are confirmed in the record. Moving there prematurely can block genuine business email. DMARC reporting is what tells you when it is safe to make the switch.
What SPF Does Not Cover
SPF only validates the envelope sender: the technical return path used during mail delivery. It does not validate the “From” address your recipient sees in their inbox. A spoofed email can pass SPF and still show your domain name convincingly in the From field.
This gap is the reason SPF alone cannot prevent impersonation. DMARC closes it through alignment, explained below. It is also a contributing factor to why Nigerian businesses experience email deliverability problems even after configuring SPF. Authentication is a system, and one record without the others leaves it incomplete.
DKIM: A Digital Signature That Travels With Every Email
How DKIM Works
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. Your mail server signs the message using a private key. A corresponding public key sits in your DNS as a TXT record.
When the message arrives, the receiving server uses your public key to verify the signature. If the message was altered in transit, even by a single character, the verification fails. A passing DKIM check confirms two things: the message arrived exactly as it was sent, and it was signed by a server with legitimate access to your private key.
DKIM Is Platform-Specific
Each mail platform generates its own DKIM key pair. Zoho Mail, Microsoft 365, and Zeptomail each use different keys. If your business uses more than one platform, each platform needs its own DKIM record in DNS, identified by a selector prefix.
For Zoho Workplace, DKIM setup is part of the full DNS configuration covered in Zoho Workplace DNS on Cloudflare. For transactional mail via Zeptomail, key generation and DNS verification are detailed in Setting Up Zeptomail for Nigerian Businesses. If you have not yet settled on a platform, Email Hosting in Nigeria: Zoho vs Microsoft 365 vs Google Workspace breaks down the options.
Every new sending service requires a new DKIM record. Businesses that skip this step send unsigned messages from those services, with no visible signal that the gap exists.
Email Forwarding Breaks SPF, but DKIM Usually Survives
When an email is forwarded, the forwarding server becomes the new sending server in the delivery chain. SPF fails because the forwarder is not on the original domain’s approved list.
DKIM behaves differently. The signature travels with the message content rather than the sending server. Unless the forwarder modifies the message body or headers, DKIM still passes.
This matters for Nigerian businesses that use domain-based forwarding, where a custom domain name redirects to a personal Gmail account, for example. In those setups, SPF fails, but DKIM can still satisfy DMARC alignment. It is one reason DKIM is considered the more reliable of the two mechanisms.
Why DKIM Alone Is Not Enough
DKIM proves message integrity and ties the message to a signing domain. It does not tell receiving servers what to do if the signature is absent or fails to verify. There is no enforcement instruction built into DKIM itself.
A fraudster can send an email from your domain without any DKIM signature at all. DKIM produces no result. Without a DMARC policy, nothing is done about that absence.
DMARC: The Policy Layer That Makes SPF and DKIM Work as a System
What DMARC Does
DMARC is where SPF and DKIM stop being two separate checks and start working as a system.
The first thing it does is introduce alignment. SPF and DKIM can both pass on technical domains your recipient never sees. DMARC checks whether those results line up with the actual “From” address, the domain name your recipient sees when they open the email. If they do not match, the message fails DMARC regardless of what the other two records said.
The second thing it does is give receiving servers explicit instructions on what to do when a message fails.
Strict vs Relaxed Alignment
Most organisations leave alignment on the default setting, which is relaxed. Under relaxed alignment, subdomains satisfy a parent domain’s DMARC check. A DKIM signature from yourbusiness.ng covers mail.yourbusiness.ng. Close enough counts.
Strict alignment requires an exact match. The signing domain must match the “From” domain exactly, with no subdomain tolerance.
This is one of the hardest DMARC failures to diagnose. SPF and DKIM both pass, the records look correct, but emails still fail DMARC because subdomains were not accounted for when the policy was set up.
The Three DMARC Policies
| Policy | What It Does | When to Use It |
|---|---|---|
p=none | Monitor only. No action on failing messages. | Starting point. See what is happening without disrupting mail flow. |
p=quarantine | Send failing messages to spam. | Once all legitimate sending sources are accounted for. |
p=reject | Block failing messages entirely. | Target state. Also the minimum required for BIMI. |
Moving directly from p=none to p=reject before all sending sources are confirmed will block legitimate business email. The staged progression exists for a reason.
DMARC Reporting: Visibility You Do Not Currently Have
The rua tag in a DMARC record specifies an address to receive aggregate reports. Sent automatically by major receiving servers, these reports show every server that sent email claiming to be your domain, whether authorised or not.
If someone is actively impersonating your domain, the reports will show it. Raw reports arrive as XML files and are not readable without a parsing tool. Services such as Postmark’s DMARC Digests, Dmarcian, or Google Postmaster Tools convert them into usable dashboards.
DMARC reports are what tell you when it is safe to progress your policy from p=none to enforcement. Without them, that decision is guesswork.
A DMARC record set to p=none with no rua address enforces nothing and monitors nothing. It provides no protection and generates no data worth acting on.
How the Three Records Work Together
Each record validates something specific and stops at something specific. That is why all three are necessary.
| Record | What It Validates | What It Cannot Do |
|---|---|---|
| SPF | Whether the sending server is authorised for your domain | Validate the visible “From” address |
| DKIM | Whether the message arrived intact, signed by your key | Enforce what happens if the signature is absent |
| DMARC | Whether SPF or DKIM results align with the visible “From” domain, and what to do if not | Work meaningfully without SPF or DKIM in place |
When all three are properly configured, a fraudster attempting to send email from your domain faces a specific problem: satisfying DMARC alignment requires either your private DKIM key or control over a server you have explicitly authorised. Neither is easily obtained.
The Parked Domain Problem Most Businesses Overlook
Any domain your business owns but does not send from is a spoofing target. Dormant domains have no SPF or DMARC records, and attackers look specifically for this.
The fix is a null SPF record, one that explicitly states no legitimate email should ever originate from this domain, paired with a DMARC reject policy. Any message claiming to come from it gets blocked.
Nigerian businesses holding multiple domains for brand protection, or because an older domain was never retired, should treat every dormant domain as an open impersonation vector until these records are in place. It is one of the simplest high-impact fixes most businesses overlook.
Why Nigerian Domains Face Closer Scrutiny from Global Mail Servers
Nigerian-originating domains carry a pre-existing reputation burden with global mail filters. This is a direct consequence of Nigeria’s historical association with email fraud, and it means Nigerian business email faces heightened scrutiny before a single message is read.
Google and Yahoo made SPF, DKIM, and DMARC effectively mandatory for bulk senders from February 2024. Microsoft followed in 2025. Together, these three providers handle approximately 90 per cent of a typical business-to-consumer email list.
The same filtering logic applies at lower send volumes, with less visibility into why messages are being deprioritised. A Nigerian domain without proper authentication carries compounded disadvantages: geography-based scrutiny on top of missing technical records.
Businesses running email through shared cPanel hosting face additional layers of this problem, as covered in cPanel Email Problems in Nigeria.
What Domain Spoofing Looks Like for a Nigerian Business
Supplier Impersonation
A fraudster identifies a vendor your business deals with regularly and sends payment instructions appearing to come from that vendor’s domain. The recipient sees a familiar name and a legitimate-looking From address. Without DMARC enforcement on the vendor’s domain, there is no technical barrier to that message landing in the inbox.
This is one of the most common business email compromise patterns affecting Nigerian organisations, and a central concern in email security for Nigerian businesses. It operates on both sides: your domain can equally be the one used against someone else.
Client-Facing Phishing Using Your Brand
Your domain is used to send phishing messages to your own clients or contacts. The attack requires only your domain name and the absence of DMARC enforcement. You may not discover it is happening until a client contacts you, or until the relationship is already damaged.
Invoice Fraud
Payment details in outgoing correspondence are replaced with fraudulent account information. The attack depends entirely on the recipient having no technical means to verify that the sending domain is legitimate. A p=reject DMARC policy removes that opening.
Authentication Is a Process, Not a One-Time Configuration
Getting SPF, DKIM, and DMARC in place is the start of a working authentication posture, not the end of it.
Rotate DKIM keys annually at minimum. Longer intervals increase the exposure window if a key is ever compromised. Every new sending platform you adopt requires an SPF update and a new DKIM record. As reporting confirms your sending sources are covered, move the policy from p=none to p=quarantine to p=reject.
Businesses that configure authentication once and walk away will drift. New services get added without SPF updates. Keys go years without rotation. The DMARC policy stays at p=none because nobody checks the reports. None of this announces itself.
Where Email Authentication Is Heading: BIMI
BIMI is where email authentication becomes visible to your customers. Brand Indicators for Message Identification displays your verified logo in the Gmail or Apple Mail inbox, next to your sender name, before the recipient opens the message.
BIMI requires a DMARC policy of at least p=quarantine, a Verified Mark Certificate from an approved certificate authority, and a correctly formatted SVG logo hosted on your domain. Certificate costs make BIMI more relevant to larger organisations at this stage, but adoption among major providers is growing.
The commercial case is clear: authentication becomes a visible inbox signal rather than a background mechanism. Getting SPF, DKIM, and DMARC properly in place is the prerequisite.
What a Properly Configured Business Domain Looks Like
Knowing the end state lets you benchmark your current setup and identify what is missing.
| Record | Target State |
|---|---|
| SPF | One record listing all sending services. Hard fail (-all) as the default stance. No DNS lookup limit breaches. |
| DKIM | Separate keys generated and published for every mail platform in use. Rotated at least annually. |
| DMARC | Policy at p=quarantine or p=reject. Active rua reporting address. Alignment mode explicitly reviewed. |
| Dormant domains | A null SPF record and a DMARC reject policy on every domain you own but do not send from. |
Most Nigerian business domains fall short on at least two of these. Getting there is not a one-afternoon task. It needs DNS access, a clear picture of every platform sending on your behalf, and some deliberate thinking before you move to p=reject.
Checking Your Current Authentication Status
MXToolbox, Google’s Admin Toolbox, and DMARC Analyser all provide free lookup tools for SPF, DKIM, and DMARC. Run your domain through any of them and compare the results against the benchmark above. Configuration errors, missing records, and stale DKIM keys are all surfaced quickly.
PlanetWeb configures email authentication for Nigerian businesses as part of email infrastructure setup and Zoho Workplace deployment. Get in touch with our team to have the records in place and verified.
