A customer receives an invoice-looking email from your business address, but you did not send it. Or your genuine quotation lands in spam just as a prospect is ready to buy. Both situations can damage trust, delay payments and cost your business opportunities. This email authentication setup guide explains how to prove that your domain is authorised to send email.
Email authentication is not an optional technical extra for serious businesses. Google, Microsoft and other major mailbox providers increasingly expect senders to authenticate their domains, especially where newsletters, invoices, support replies and transactional messages are involved. The good news is that the core setup relies on DNS records and can usually be managed from your domain control panel or hosting account.
What email authentication actually does
Email authentication uses three standards – SPF, DKIM and DMARC – to help receiving mail servers verify who is allowed to send messages using your domain. They work together, but each has a different role.
SPF states which servers or services may send email for your domain. DKIM adds a cryptographic signature to outgoing messages, allowing receiving servers to confirm that the message was authorised and was not altered in transit. DMARC tells receiving servers what to do when SPF or DKIM checks fail, while also providing reports on attempted use of your domain.
Think of SPF as an approved-senders list, DKIM as a tamper-evident business seal, and DMARC as the policy that enforces the checks. None is a substitute for good passwords, two-factor authentication or staff awareness. They are a separate layer that protects your domain reputation and reduces email spoofing.
Before you add DNS records
Start by mapping every platform that sends email using your domain. This is where many otherwise correct configurations fail. Your business may send through cPanel webmail, Microsoft 365, Google Workspace, a website contact form, WooCommerce, an invoicing platform, a CRM, a helpdesk or a marketing tool. Each legitimate sender must be considered.
Check where your DNS is hosted. It may be at your domain registrar, your hosting provider or a separate DNS service. The records must be added where your domain’s active nameservers are managed, not simply wherever you bought the domain.
Also inspect your existing DNS zone before creating anything new. A domain must have only one SPF TXT record. Adding a second SPF record is a common mistake and can cause SPF to fail completely. DKIM and DMARC can have their own distinct records, but existing entries should be reviewed rather than overwritten blindly.
DNS changes are not always immediate. Some updates appear within minutes, while others can take several hours to propagate depending on the record’s TTL and DNS provider. Plan the work at a quiet time, but do not panic if a test does not pass straight away.
Email authentication setup guide: configure SPF
An SPF record is a TXT record placed at the root of your domain. It identifies approved sending sources. A simple example might look like this:
v=spf1 include:example-mail-provider.com -allDo not copy that example into your DNS zone. The correct value depends entirely on your email provider and any third-party platforms that send on your behalf. Your business email provider should supply the exact SPF include statement or IP address to use.
If you use more than one sending service, their mechanisms need to be combined into one record. For example, your business email service and email marketing provider may each give you an include: value. These should be assembled into a single SPF string, ending with an appropriate policy.
The ending matters. -all is a hard fail and says that all unlisted senders are unauthorised. ~all is a soft fail, which is often used while a business is still identifying every sending source. A hard fail gives stronger protection, but only after you are confident the record covers all legitimate services. If a forgotten website form sends through another server, a strict record can affect its deliverability.
SPF has a technical lookup limit. Overloading the record with many services can cause a PermError, so larger businesses should consolidate platforms where possible and review their sending stack regularly.
Enable DKIM for every sending platform
DKIM is normally enabled inside the control panel of your email service, then published in DNS as a TXT or CNAME record. Unlike SPF, it is normal to have multiple DKIM records because each provider can use its own selector.
A DKIM record is typically placed under a name similar to selector._domainkey.yourdomain.com. The selector is chosen by the provider and may look like default, s1 or a longer generated value. Copy both the host name and value exactly as supplied. A missing character, incorrect quotation mark or record placed under the wrong hostname will prevent verification.
For hosted business email, your hosting control panel may offer a one-click option to enable DKIM. On a cPanel-based account, look for Email Deliverability or the relevant email authentication area. GiddyHost customers using supported cPanel email services can use this interface to view and repair recommended records without manually guessing values.
After publishing DKIM, send a message to a test mailbox and inspect the message headers. Look for a result such as dkim=pass. A pass confirms that the receiving server can validate the signature. It does not guarantee inbox placement on its own, but it is a key signal for trustworthy sending.
Add DMARC carefully, then strengthen it
DMARC is published as a TXT record at _dmarc.yourdomain.com. A basic monitoring record can look like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100The p=none policy asks receivers to take no enforcement action while sending aggregate reports to the nominated address. This is the safest starting point because it lets you see which services are sending as your domain before messages are quarantined or rejected.
Create a dedicated mailbox for reports if possible. DMARC aggregate reports are machine-readable and can arrive frequently, so they are not pleasant reading in a busy personal inbox. You can review them through a reporting tool or ask a technically experienced administrator to interpret them.
Once you have confirmed that your genuine mail passes SPF or DKIM and aligns with your visible From address, move gradually to p=quarantine. This asks receivers to treat failing messages with suspicion, often by placing them in spam. The strongest policy is p=reject, which asks receivers to refuse unauthorised mail altogether.
There is no prize for reaching reject quickly. A startup using only one email platform may validate its setup in a short period. An established Nigerian company with multiple branches, CRM automations, old website forms and agency-managed campaigns may need more time. DMARC protects best when it is accurate, not when it is rushed.
Test alignment, not just individual records
A domain can technically publish SPF, DKIM and DMARC records and still fail DMARC. The missing piece is alignment. The domain checked by SPF or signed by DKIM must align with the domain shown in the visible From address.
For example, a mailing platform may pass SPF using its own domain rather than yours. If its DKIM signature is also not aligned with your From domain, DMARC can fail even though the platform claims it is authenticated. Configure custom sending domains within third-party platforms rather than relying on their default shared settings.
Test the main email journeys your customers receive: a direct staff email, website enquiry acknowledgement, password reset, order confirmation, invoice and marketing campaign. Check the headers for spf=pass, dkim=pass and dmarc=pass. Testing only one staff mailbox is not enough when several systems send email.
Problems that commonly affect Nigerian businesses
A website moved to a new host may still send through the old server, particularly when a developer hard-coded SMTP details years ago. A WordPress site that uses PHP mail can also produce inconsistent results and poor traceability. Where possible, configure authenticated SMTP through a recognised mail service rather than relying on default server mail functions.
Another issue is sending from a free mailbox while presenting a business identity. A Gmail or Yahoo address may be convenient at the beginning, but it gives you limited control over your sending reputation and cannot authenticate your own business domain. Sending from name@yourbusiness.ng or your chosen domain presents a more credible, manageable identity.
Finally, authentication will not fix poor sending practices. Purchased contact lists, misleading subject lines, sudden volume spikes and outdated addresses can still lead to spam complaints. Keep consent records, remove invalid addresses and send messages your recipients genuinely expect.
Email authentication is a practical investment in customer confidence. Set it up methodically, monitor the results and tighten your DMARC policy when every authorised sender is accounted for. Your next invoice, campaign or support reply should arrive looking exactly like it came from you – because the receiving server can prove that it did.
