Email Authentication in Nigeria: The Records That Protect a Domain from Fraud
Without a DMARC policy, nothing instructs receiving servers to reject emails that falsely claim to come from a business domain. Anyone can send a message that appears to come from that domain.
Clients, suppliers or partners could then receive a fraudulent email that looks like it came from the organisation, and the business may not know until someone makes contact or the damage is done.
SPF, DKIM and DMARC are the three DNS records that address this, and they work as a system. Each one covers gaps the others leave open.
The Design Flaw at the Heart of Email
SMTP, the protocol that moves messages between servers, dates back to the early 1980s and was designed for a small network where trust between participants was assumed. Sender verification was never included, so any server can still claim to be any domain.
SPF, DKIM and DMARC arrived decades later as retrofitted fixes. Valimail’s 2026 State of DMARC Report notes that most domains with DMARC are not fully protected, because many publish a record without moving to enforcement, meaning a quarantine or reject policy.
SPF: Telling the Internet Which Servers Can Send on a Domain’s Behalf
How SPF Works
SPF (Sender Policy Framework) is a TXT record published in a domain’s DNS. It lists every mail server authorised to send on the domain’s behalf. When a receiving server gets a message claiming to be from that domain, it checks the record, and a sending server missing from the list fails SPF. What the receiver does with a failed result depends largely on the domain’s DMARC policy.
What an SPF Record Looks Like
An SPF record is a single line of text in DNS that carries a version identifier, lists every authorised sending service and ends with a default stance on anything else. Each platform the domain sends from needs its own entry in that record. WordPress and WooCommerce sites using Zoho CPaas can find the full setup in the ZeptoMail WordPress integration guide.
A domain can have only one SPF record. A second one causes SPF evaluation to fail, so neither record works. This is a common mistake when a business adds a new sending service by creating a fresh record instead of updating the existing one.
SPF also has a limit of ten DNS lookups per evaluation. A business using several sending platforms can breach this limit and see failures even with every service listed.
Hard Fail and Soft Fail: Choosing the SPF Ending
The ~all tag produces a soft fail. It tells receiving servers that an unlisted sender is probably not authorised, but leaves the final handling to the receiver. The alternative, -all, is a hard fail that tells receivers an unlisted sender is not authorised and can be rejected.
A soft fail may feed into spam scoring at some receivers, but on its own it offers little barrier to spoofing.
Both endings are legitimate, and the right one depends on how strongly DMARC is enforced. Where DMARC is at enforcement, many organisations keep ~all and let DMARC make the decision.
A hard fail should only be applied once every legitimate sending source is confirmed. It can also create problems for forwarded mail, because the forwarding server may not be authorised by the original SPF record. DMARC reporting shows when a change is safe.
What SPF Does Not Cover
SPF validates only the envelope sender, which is the technical return path used during mail delivery, and leaves the “From” address that the recipient sees in the inbox unchecked. A spoofed email can pass SPF and still show the business’s domain name convincingly in the “From” field.
This gap is why SPF alone cannot prevent impersonation. DMARC closes it through alignment, explained below. Incomplete authentication also feeds the problems covered in email deliverability in Nigeria.
DKIM: A Digital Signature That Travels With Every Email
How DKIM Works
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. The mail server signs the message with a private key, and the matching public key sits in DNS as a TXT record.
When the message arrives, the receiving server uses the public key to verify the signature. If the message is altered in a way that changes the signed content, verification can fail. A passing check confirms that the signed content arrived intact and that it was signed by a server with legitimate access to the private key.
DKIM Is Platform-Specific
Each mail platform generates its own DKIM key pair. Zoho Mail, Microsoft 365 and Zeptomail, which is now part of Zoho CPaaS, each use different keys. A business using more than one platform needs a separate DKIM record in DNS for each, identified by a selector prefix.
Zoho Workplace DNS on Cloudflare covers DKIM setup for Zoho Workplace, and Zeptomail in Nigeria covers the records Zoho displays for transactional mail. A business still choosing a platform can compare the options in Email Hosting in Nigeria.
Every new sending service requires a new DKIM record. A business that skips this step sends unsigned messages from that service, 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 then fails because the forwarder is not on the original domain’s approved list.
DKIM behaves differently. The signature is attached to the message itself, so unless the forwarder modifies the body or headers, DKIM still passes.
This matters for Nigerian businesses that forward a custom domain to a personal Gmail account. SPF fails in that setup, but DKIM can still satisfy DMARC alignment, a check explained in the DMARC section below. That is why DKIM is often considered the more reliable of the two.
Why DKIM Alone Is Insufficient
DKIM proves message integrity and ties the message to a signing domain, but it carries no instruction for receiving servers when a signature is absent or fails to verify.
A fraudster can send an email from a domain without any DKIM signature at all. DKIM then produces no result, and 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 together.
It first introduces alignment. SPF and DKIM can both pass on technical domains the recipient never sees, so DMARC checks whether at least one of those results aligns with the “From” address shown in the inbox. If neither SPF nor DKIM passes with alignment, the message fails DMARC.
Most organisations leave alignment on the default setting, which is relaxed. Under relaxed alignment, a parent domain and its subdomains can align, so a DKIM signature from yourbusiness.ng can align with a “From” address using mail.yourbusiness.ng. Strict alignment requires the signing domain to match the “From” domain exactly.
Alignment failure is one of the hardest DMARC problems to diagnose, because SPF and DKIM both pass and the records look correct. Subdomains that were not accounted for when the policy was set up are a common cause.
The Three DMARC Policies
Beyond alignment, DMARC gives receiving servers explicit instructions on what to do when a message fails.
| Policy | What It Does | When to Use It |
|---|---|---|
p=none | Monitor only. Requests no specific DMARC action on failing messages. | Starting point. Shows what is happening without changing normal mail handling. |
p=quarantine | Asks receivers to treat failing messages as suspicious, often by sending them to spam. | Once all legitimate sending sources are accounted for. |
p=reject | Asks receivers to reject failing messages. | Target state once reporting confirms every legitimate source passes. |
Moving directly from p=none to p=reject before all sending sources are confirmed can cause legitimate business email to be rejected. The staged progression exists for that reason.
DMARC Reporting: Seeing Who Sends on a Domain’s Behalf
The rua tag in a DMARC record specifies an address that receives aggregate reports. Participating receiving servers can send these reports automatically, showing the sources they observed sending messages that claim to use the domain, whether authorised or not.
If someone is actively impersonating the domain, the reports can show it.
Raw reports arrive as XML files that are unreadable without a parsing tool, and services such as Postmark’s DMARC Digests and Dmarcian convert them into usable dashboards. Google Postmaster Tools is a separate service that complements them by showing spam rate and domain reputation for mail sent to Gmail users.
These reports tell a business when it is safe to move from p=none to enforcement. Without them, that decision is guesswork. A p=none record with no rua address enforces nothing and gives the domain owner no data to analyse.
How the Three Records Cover Each Other’s Gaps
Each record validates something specific and stops at something specific. SPF checks the sending server but not the visible “From” address, DKIM checks that the message arrived intact but cannot enforce anything, and DMARC ties the results to the “From” domain and sets the response.
When all three are properly configured, and DMARC is enforced, a fraudster attempting to spoof the domain has to get an aligned SPF or DKIM result to pass DMARC. In practice, that means a DKIM signature from an aligned domain or an authorised sending source that passes SPF with alignment. Both are difficult to obtain without access to legitimate sending infrastructure.
Why Mailbox Providers Now Require Authentication
Google and Yahoo introduced stricter authentication requirements for bulk senders in 2024, and Microsoft introduced comparable requirements for high-volume senders to Outlook.com in 2025. Google and Microsoft use thresholds of around 5,000 messages a day for their consumer mail services.
Google’s sender guidelines also ask every sender to authenticate with SPF or DKIM, so a Nigerian business sending far below those volumes still benefits from having all three records in place. The detail on bulk-sender rules is in Google’s email sender guidelines.
Businesses running email through shared cPanel hosting face additional authentication problems, which cPanel Email Problems in Nigeria sets out.
The Parked Domain Problem That Businesses Often Overlook
Any domain a business owns but does not send from is a spoofing target. Dormant domains usually have no SPF or DMARC records, and attackers look specifically for this.
The fix is a null SPF record, which states that no legitimate email should ever originate from the domain, paired with a DMARC reject policy. Receivers that honour the policy then reject any message claiming to come from it.
Nigerian businesses that hold multiple domains for brand protection, or because an older domain was never retired, should treat every dormant domain as an open impersonation route until these records are in place.
What Domain Spoofing Looks Like for a Nigerian Business
Supplier Impersonation and Invoice Fraud
A fraudster identifies a vendor that a business deals with regularly and sends payment instructions that appear to come from the vendor’s domain. The recipient sees a familiar name and a legitimate-looking “From” address, and without DMARC enforcement on the vendor’s domain, there is no technical barrier to the message reaching the inbox. Altered bank details on an otherwise genuine-looking invoice work the same way.
This is a form of business email compromise, which email security for Nigerian businesses treats as a central concern. The risk runs in both directions, because a business’s own domain can equally be the one used against someone else. A p=reject DMARC policy on the business’s own domain closes that opening at receivers that honour it.
Client-Facing Phishing Using a Brand
A business’s domain can be used to send phishing messages to its own clients or contacts. The attack requires only the domain name and the absence of DMARC enforcement.
Authentication Needs Ongoing Maintenance
Getting SPF, DKIM and DMARC in place is the start of a working authentication posture. It takes continued attention to stay effective.
Some security guidance recommends rotating DKIM keys periodically, particularly for high-value domains or long-lived keys, since longer intervals widen the exposure window if a key is ever compromised.
Every new sending platform requires an SPF update and a new DKIM record. Reporting shows when the policy can safely move up a stage.
A business that configures authentication once and walks away will drift, and none of the drift announces itself.
Where Email Authentication Is Heading: BIMI
Brand Indicators for Message Identification (BIMI) allows participating mailbox providers, including Gmail and Apple Mail, to display a brand logo beside authenticated messages. It requires a DMARC policy at enforcement, meaning p=quarantine or p=reject, and a correctly formatted SVG logo hosted on the domain.
Depending on the mailbox provider, it may also require a Verified Mark Certificate or Common Mark Certificate from an approved certificate authority. Certificate costs make BIMI more relevant to larger organisations at this stage, although adoption among major providers is growing.
What a Properly Configured Business Domain Looks Like
The end state below works as a benchmark for a current setup.
| Record | Target State |
|---|---|
| SPF | One record listing all sending services, with a deliberate choice between ~all and -all. No DNS lookup limit breaches. |
| DKIM | Separate keys generated and published for every mail platform in use, and rotated periodically. |
| 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 owned but not used for sending. |
Getting there takes DNS access, a clear picture of every platform sending on the business’s behalf, and some deliberate planning before moving to p=reject.
MXToolbox, Google’s Admin Toolbox and DMARC Analyser all provide free lookup tools for SPF, DKIM and DMARC. Running a domain through any of them and comparing the results against the benchmark quickly surfaces configuration errors, missing records, and stale DKIM keys.
Businesses that send transactional and marketing email from the same domain will find the split explained in transactional email vs email marketing, which covers why the two streams are often kept on separate subdomains.
Need Help Putting Email Authentication in Place?
If you are unsure what your domain currently publishes, we can check it and fix what is missing. PlanetWeb configures email authentication for Nigerian businesses as part of email infrastructure setup and Zoho Workplace deployment, and our Zoho Setup and Migration service covers the DNS work involved.
To have the records put in place and verified, speak with our team. It helps to bring the domain name, a list of every service that sends email for it, and access details for the DNS host.
