🎤 This mode is just for fun lah. Some technical nuances might be simplified or lost in translation. We also used AI to help write these (where got time to do one by one). For the accurate stuff, switch back to the other modes.
What is Email Deliverability?
Email deliverability is the likelihood that an email you send actually reaches the recipient's inbox — not their spam folder, and not silently dropped altogether. Poor deliverability is usually caused by missing configuration, a bad sender reputation, or using a mail setup that inbox providers don't trust.
Deliverability is the measure of whether outbound mail successfully reaches the recipient's inbox. It is affected by DNS authentication records (SPF, DKIM, DMARC), IP and domain reputation, bounce rates, spam complaints, message formatting, and the sending infrastructure used. Inbox providers like Google and Microsoft use a combination of these signals to classify or reject mail.
Email deliverability, wah, sounds chim right? But actually very simple one lah. It just means: when you send an email, does it actually reach the person's inbox? Or does it go to spam? Or worse, just disappear into thin air like your Grab driver who cancelled on you. If your emails keep going to spam, it's usually because of missing settings, bad reputation, or your email setup is the equivalent of a letter with no return address.
SPF
A list of servers that are allowed to send email on behalf of your domain. If someone else tries to send email pretending to be you, receiving servers can check this list and reject it.
Sender Policy Framework — a DNS TXT record that lists the IP addresses and mail servers authorised to send mail from your domain. During delivery, the receiving server checks the SPF record against the sending server's IP. A fail result can cause mail to be rejected or marked as spam.
SPF is basically a bouncer list for your domain. You publish a list of servers that are allowed to send emails on your behalf. If someone tries to send email pretending to be you from a random server, the receiving side checks the list and goes "Eh, you not on the list leh. Cannot enter." Like club bouncer, but for emails.
DKIM
A digital signature attached to every email you send. The receiving server checks the signature to confirm the email genuinely came from your mail server and wasn't tampered with in transit.
DomainKeys Identified Mail — a cryptographic signature added to the email header. The sending server signs the message with a private key; the public key is published in a DNS TXT record. Receiving servers verify the signature to confirm authenticity and content integrity.
DKIM is like a tamper-proof seal on every email you send. Your email server sticks a digital signature on the message. When it arrives, the receiving server checks: "Is this signature legit? Nobody messed with the contents?" If everything matches, the email is trusted. It's like those wax seals people used on letters last time - fancy and secure.
DMARC
A policy you publish that tells receiving mail servers what to do if an email fails SPF or DKIM checks — nothing, send it to spam, or reject it outright. It also sends you reports on who is sending email using your domain name.
Domain-based Message Authentication, Reporting and Conformance — a DNS TXT record that declares a policy (none, quarantine, or reject) for messages that fail SPF or DKIM alignment, and specifies reporting addresses for aggregate (rua) and forensic (ruf) reports. DMARC requires alignment: the authenticated domain must match the header From address.
DMARC is the boss that ties SPF and DKIM together. It tells receiving servers: "If an email claims to be from my domain but fails the checks, here's what you should do - ignore it, quarantine it, or straight up reject it." It also sends you reports so you can see who's been trying to send emails using your domain name. Very shiok to catch imposters.
Why all three matter
SPF and DKIM alone are not enough — DMARC ties them together and tells receiving servers what to do when checks fail. Without all three, your domain is easier to spoof and your mail is more likely to be treated as suspicious, even if you're sending legitimately.
SPF alone can be bypassed (it checks the envelope sender, not the header From). DKIM alone doesn't prevent spoofing of the visible From address. DMARC enforces alignment between these checks and the visible From domain, and provides reporting so you can see who is sending mail on your behalf — authorised or not.
SPF alone can be tricked. DKIM alone doesn't stop people from faking your email address. But DMARC? DMARC ties everything together and says "Check must match, or no entry." Without all three, your domain is like a house with no lock, no gate, and no CCTV. You're basically telling scammers "Come, help yourself."
Group Inboxes vs Individual Inboxes
Many organisations make the mistake of creating personal email accounts for shared roles — like giving one staff member a billing@ address tied to their personal inbox. When that person leaves, you lose access. And paying for a full email licence per person for a role address is wasteful.
Role-based addresses — info@, billing@, support@, volunteers@ — should be group inboxes, not individually-licensed mailboxes. Most cloud email providers support this through distribution lists, shared mailboxes, or groups, typically at no additional licence cost. This reduces seat spend significantly while improving operational continuity.
Wah, this one so many organisations get wrong. They create a billing@ email and give it to one person. That person leaves, and suddenly nobody can access billing emails. Or they pay full licence for info@, admin@, volunteer@ - sibeh waste of money. Group inboxes solve this and save you a lot of headache.
Save on licence seats
Instead of paying for a full email licence for billing@, info@, and admin@, you can create these as shared group inboxes that multiple people can access — without paying for separate seats for each address.
In Google Workspace, Groups can be used as collaborative inboxes with no additional licence cost — multiple users access the same inbox via their own accounts. Microsoft 365 supports shared mailboxes (up to 50GB free) accessible by licensed users. Neither approach requires a separate paid licence for the role address itself.
Instead of paying for a full email licence for every role address - billing@, info@, admin@ - just make them group inboxes lah. Multiple people can access it using their own accounts, no extra cost. It's like sharing a Netflix account but actually legal and your IT admin approves.
Better continuity
If the person who owns the info@ email leaves, and it was linked to their personal account, you might lose all those emails. With a group inbox, multiple people always have access, and nothing is lost when someone moves on.
Personal mailboxes tied to an individual licence create a single point of failure. Group inboxes or shared mailboxes are owned by the organisation, not the individual. Access is managed centrally and survives staff turnover without data loss or account recovery headaches.
If the person who manages info@ leaves, and that email is tied to their personal account, you're cooked. All those emails, gone. With a group inbox, multiple people always have access. Staff come and go, but the organisation's emails stay safe. Like having multiple key holders for the office - one person resign, others can still unlock.
When to use a personal licence
Full personal email licences make sense for staff who send and receive email regularly in their own name — like a director or programme manager. Role addresses like info@ or support@ almost never need their own seat.
Licence a mailbox per person when they need calendar, drive, contacts, or personal email with their name as the sender. For purely functional addresses — info@, noreply@, billing@ — use a group, alias, or shared mailbox. Avoid paying for a full licence just to have an address that forwards or is accessed by a team.
Full personal email licences make sense for people who need their own identity - like your director or programme manager sending emails as themselves. But info@? support@? billing@? These don't need their own seat lah. That's like buying a whole car just to go to the mamak downstairs.
Cloudflare DMARC Management
If your domain is managed through Cloudflare, they offer a free tool that reads your DMARC reports for you and shows them in a clear dashboard. Instead of receiving raw data files, you can see at a glance who is sending email using your domain name — including any unauthorised senders.
Cloudflare DMARC Management is a free feature for domains on Cloudflare that parses and aggregates DMARC aggregate reports (rua). It sets up a dedicated reporting address, processes incoming XML reports, and presents a dashboard showing authenticated vs unauthenticated sources, SPF/DKIM pass rates, and volume by sender. It substantially lowers the barrier to acting on DMARC data.
If your domain is on Cloudflare (and after following our other guide, it should be), they have this free DMARC dashboard that's actually quite power. Instead of getting ugly XML reports that nobody can read, Cloudflare shows you a nice clean dashboard: who's sending email using your domain, and whether those emails passed or failed the checks. Free some more.
What it shows you
The dashboard lists every server that has sent an email claiming to be from your domain, whether those emails passed the security checks, and roughly how many were sent. This helps you spot anyone trying to impersonate your organisation.
The dashboard surfaces per-source DMARC aggregate data: sending source (IP/hostname), SPF result and alignment, DKIM result and alignment, DMARC disposition, and message volume. This is essential before moving a DMARC policy from p=none to p=quarantine or p=reject.
The dashboard shows you every server that sent email claiming to be from your domain. Passed the checks? Green tick. Failed? Red cross. It even tells you how many emails each source sent. Super useful for catching people who are spoofing your domain or for making sure all your legit services are properly set up.
How to enable it
Log in to Cloudflare, go to your domain, and look for "Email" in the sidebar — then "DMARC Management". Cloudflare will set up the reporting address automatically. You just need to confirm your DMARC record is in place.
Enable via the Cloudflare dashboard under Email > DMARC Management. Cloudflare creates a managed rua reporting address and adds or updates your DMARC TXT record to include it. Reporting data begins accumulating within 24-48 hours. Existing DMARC policies are respected — it only adds the reporting component.
Log in to Cloudflare, go to your domain, click "Email" in the sidebar, then "DMARC Management". Cloudflare will set up the reporting address for you automatically. You just make sure your DMARC record is in place. Easy peasy, five minutes job, and you get proper email intelligence for your domain.
Transactional Mail vs Regular Mail
Not all email is the same. There are two main types, and they should generally be sent through different systems. Mixing them up is a common cause of deliverability problems.
Transactional and marketing/operational mail have different deliverability profiles and requirements. Sending both through the same infrastructure risks having high-volume or complaint-prone marketing mail damage the reputation of your transactional stream — which can cause critical system emails to fail delivery.
Not all emails are the same lah. This one very important to understand. There are two types, and if you mix them up, you're asking for trouble. It's like putting your chicken rice and your bubble tea in the same container - technically possible, but why would you do that?
Transactional mail
These are automated emails triggered by an action — a registration confirmation, a password reset, a receipt, or an alert. They're expected by the recipient and need to arrive reliably. Examples: "Your booking is confirmed" or "Someone requested a password reset on your account."
Transactional email is 1:1, triggered by a user action, and has high expected delivery reliability. It should be sent through a dedicated transactional mail service — Postmark, Mailgun (transactional tier), SendGrid, or AWS SES. These services maintain high-reputation sending infrastructure, offer detailed delivery logs, and are optimised for reliability over volume.
These are the automated emails: "Your order is confirmed", "Reset your password", "Someone logged into your account." The person is expecting this email. It MUST arrive reliably. If your password reset email lands in spam, your user is stuck. Send these through a proper transactional mail service - Postmark, SendGrid, Brevo. Don't cheap out here.
Regular/bulk mail
These are emails you send to a list — newsletters, announcements, event invitations, fundraising appeals. They go to many people at once and are more likely to be marked as spam if not managed carefully. Examples: a monthly newsletter or a donation campaign email.
Bulk/marketing email is 1:many, often scheduled or campaign-based, and is subject to higher spam complaint rates. It should be sent through a dedicated platform — Mailchimp, Campaign Monitor, Brevo, or similar — that manages unsubscribes, list hygiene, bounce handling, and compliance (CAN-SPAM, GDPR). Never send bulk mail through your personal or organisational email account.
These are your newsletters, event invitations, fundraising campaigns - emails you send to a list of people. More likely to get spam complaints because not everyone wants your monthly update (sorry but it's true). Use a proper email platform like Mailchimp or Brevo. Never ever send bulk email from your personal Gmail or Outlook. That's how you get your whole domain blacklisted.
Why to keep them separate
If you send newsletters and password resets from the same email account and someone marks your newsletter as spam, it can damage the reputation of all your emails — including the critical ones. Keeping them on separate systems protects your important emails.
Mixing transactional and bulk mail on the same IP or domain means spam complaints from marketing campaigns can raise complaint rates and damage the sender reputation affecting your transactional stream. Dedicated infrastructure, separate subdomains (e.g. mail.yourorg.org vs noreply.yourorg.org), and separate DKIM selectors are best practice.
Imagine you send newsletters and password reset emails from the same account. Someone marks your newsletter as spam (rude, but it happens). Now your sender reputation drops, and suddenly your password reset emails also go to spam. Your users cannot reset their passwords. Total disaster. Keep them separate - different systems, different subdomains. Insurance policy lah.
Self-Hosted Email vs Cloud Email
Some organisations host their own email on their web hosting account (like cPanel) instead of using a cloud service like Google Workspace or Microsoft 365. While this seems cheaper, it often causes serious deliverability problems that are hard to fix.
Self-hosted mail — typically run via cPanel/Exim or Postfix on shared or VPS hosting — carries significant deliverability risk compared to dedicated cloud mail providers. The underlying infrastructure, IP reputation, and spam management tooling simply aren't comparable to purpose-built mail services.
Some organisations host their own email on their web hosting (like cPanel). Seems cheaper right? Wrong. It's like cooking at home to save money but using ingredients from 7-Eleven - technically possible, but don't expect Michelin star results. Self-hosted email is a deliverability nightmare that will slowly drive you siao.
The shared IP problem
When you host email on a shared hosting server, your emails share the same internet address as dozens or hundreds of other websites and email accounts. If any of them send spam, your emails suffer for it — even if you're doing everything right. Inbox providers look at the sending address's history, and a bad neighbour can get you blocked.
Shared hosting uses a pool of shared IPs for outbound mail. If any tenant on that IP is flagged for spam, the IP's reputation degrades for all users. Inbox providers (particularly Gmail and Outlook) maintain real-time blocklists keyed on sending IP. Without a dedicated IP and proactive reputation management, self-hosted mail on shared infrastructure is high-risk.
When you host email on shared hosting, your emails share the same internet address as hundreds of other websites. If even ONE of them sends spam, your emails suffer too. It's like sharing a flat with a terrible housemate who keeps burning food - the whole building knows, and everyone thinks it's you. Bad neighbours = bad email reputation.
Mail score and reputation
Mail providers score your emails based on many factors — your sending history, how often recipients mark you as spam, how many of your emails bounce, and whether your security records are set up correctly. A low score means your emails land in spam. Cloud providers like Google maintain strong scores by design; self-hosted servers start from scratch and need constant attention.
Sender reputation is a composite score maintained by each receiving provider, based on: IP reputation, domain reputation, engagement rates (opens, clicks), spam complaint rate, hard/soft bounce rates, and the presence of SPF/DKIM/DMARC. Cloud providers like Google Workspace and Microsoft 365 operate dedicated mail infrastructure with monitored IP pools, purpose-built for high deliverability. Self-hosted servers require manual attention to all of these factors.
Every email provider gives your sending address a score. Good history? High score. People keep marking you as spam? Low score. Lots of bounced emails? Even lower. Big cloud providers like Google Workspace maintain good scores automatically because they have proper infrastructure. Self-hosted? You start from zero and have to grind for every single point. Like building credit score from scratch.
When self-hosted might still be acceptable
If your organisation only sends a very small number of internal emails and rarely sends to external addresses, self-hosted mail may be workable — but even then, it requires careful configuration. For any organisation that relies on email for public communication, a cloud provider is strongly recommended.
Self-hosted mail is defensible for low-volume internal use on a dedicated VPS with a clean IP, full SPF/DKIM/DMARC configuration, and active monitoring. For anything outward-facing — donor communication, public contact forms, newsletters — cloud email providers offer substantially better deliverability with far less operational overhead. For charities, Google Workspace and Microsoft 365 are available free through their nonprofit programs.
If your organisation only sends maybe 10 internal emails a day and rarely contacts external people, self-hosted might be OK lah. But for anything public-facing - donor emails, newsletters, contact forms - please just use a cloud provider. Google Workspace and Microsoft 365 are free for nonprofits through their charity programs. Free is free, don't kalah to free.
WordPress & PHP Mail
If your WordPress website sends emails — like contact form submissions, user registrations, or WooCommerce order confirmations — and those emails are landing in spam or not arriving at all, the cause is almost always the same: WordPress is using a basic mail method called PHP mail that isn't trusted by modern inbox providers.
WordPress uses PHP's mail() function by default. This sends mail directly from the web server without DKIM signing, often with no meaningful SPF coverage, and from an IP address associated with web hosting rather than a trusted mail service. Modern inbox providers frequently reject or filter this mail, particularly from shared hosting environments.
If your WordPress website sends emails - contact forms, signups, WooCommerce orders - and they keep landing in spam or vanishing completely, I can tell you the problem right now: PHP mail. WordPress uses this ancient method called PHP mail that modern email providers simply don't trust. It's like showing up to a job interview in your pajamas. Technically you showed up, but nobody's taking you seriously.
Why PHP mail goes to spam
PHP mail is like sending a letter without a return address, no stamp, and from a location that spam filters already distrust. It has no authentication — there's nothing to prove the email actually came from your website legitimately — so spam filters treat it as suspicious.
mail() sends via the local MTA (typically Postfix or Sendmail on the hosting server) with no DKIM signature and often no SPF alignment. The sending IP is a shared web hosting IP — not whitelisted for mail, frequently flagged, and carrying reputation damage from other tenants. There is no retry logic, bounce handling, or delivery logging. It's the worst possible sending method for anything important.
PHP mail is like sending a letter with no return address, no stamp, and delivered by a stranger in a trenchcoat. There's no authentication at all - nothing proves the email actually came from your website. And it sends from the same IP address as other random websites on your shared hosting. Spam filters look at this and go "Nah, don't trust."
The fix: SMTP with a proper mail service
The solution is to configure WordPress to send mail through a proper mail service using a method called SMTP. You set up a free account with a mail delivery service (like Brevo or Mailgun), install a free WordPress plugin, and connect them. After that, your WordPress emails are sent through trusted infrastructure with proper authentication.
Replace mail() with SMTP via a transactional mail provider — Brevo (free tier: 300 emails/day), Mailgun, SendGrid, or Postmark. Install a WordPress SMTP plugin (FluentSMTP, WP Mail SMTP) and configure it with the provider's SMTP credentials. The provider handles DKIM signing, SPF alignment, bounce processing, and delivery logs. This alone resolves the vast majority of WordPress mail deliverability issues.
The fix is actually simple: make WordPress send emails through a proper mail service using SMTP. Sign up for a free account with Brevo (300 free emails per day), install a free WordPress plugin like FluentSMTP, connect them. Done. Your WordPress emails now go through trusted infrastructure with proper authentication. Five minutes of work, deliverability problems solved.
Contact forms specifically
Contact form plugins like Contact Form 7 or WPForms also rely on PHP mail by default. The same fix applies — configure SMTP through a mail delivery service and all form notifications will go through trusted infrastructure. Additionally, make sure your contact forms send from an address at your own domain, not a visitor's email address.
Contact form plugins typically set the From address to the visitor's submitted email and use mail() to send notifications to the site admin. This causes SPF and DKIM failures because the From domain doesn't match the sending server. Set the From address to a fixed address at your own domain (e.g. forms@yourorg.org) and use the visitor's email as Reply-To only. Combine with SMTP configuration above.
Contact Form 7, WPForms, all the contact form plugins - same PHP mail problem. But there's an extra gotcha: by default they try to send FROM your visitor's email address, which obviously fails because your server isn't your visitor's email provider. Fix: set the From address to something@yourdomain.com and put the visitor's email as Reply-To. Then add SMTP. Problem solved.
Email Spoofing & Header Manipulation
One of the most important things to understand about email is that anyone can put any email address in the "From" field of an email. Just like you could write any return address on an envelope, email headers can be faked. This is how scammers impersonate real organisations — and why SPF, DKIM, and DMARC exist.
SMTP does not natively authenticate the sender's identity. The MAIL FROM (envelope sender) and the header From address are separate and independently settable. A bad actor can trivially set the header From to any address — including yours — while routing the mail through their own infrastructure. This is the technical basis for phishing, business email compromise (BEC), and impersonation attacks.
OK this one is scary but you need to know. Anyone - literally anyone - can put any email address in the "From" field of an email. It's like writing any return address on an envelope. You can write "Buckingham Palace" on the back of your letter, doesn't mean you're the King. This is literally how scammers impersonate real organisations. And this is exactly why SPF, DKIM, and DMARC are not optional.
How spoofing works
When a scammer wants to impersonate your organisation, they simply configure their mail software to say it's from your address — info@yourorg.org, for example. Without the right security records on your domain, there's nothing stopping this. Recipients see your name and address and may trust it completely.
An attacker can set arbitrary RFC 5322 header From values when sending via SMTP. Without DMARC enforcement on the target domain, receiving servers have no policy-based mechanism to reject such mail. SPF passes if the attacker's own domain passes SPF for the MAIL FROM — the header From is irrelevant to SPF alone. DMARC with p=reject is the primary defence against header From spoofing.
Scammer wants to pretend to be your organisation? Easy - they just type info@yourorg.org in the "From" field of their email software. Without DMARC on your domain, receiving servers have no way to know it's fake. The recipient sees your organisation name and email address, trusts it completely, and clicks the dodgy link. Walao, that's how people get phished.
Display name spoofing
Even when a domain has strong security in place, scammers can still use a fake display name like "DigiHwy Certainty" with a completely different email address behind it. Many email clients show only the display name by default — always check the actual email address before trusting a message, especially if it asks you to take action.
Display name spoofing bypasses DMARC entirely — the header From can read Your CEO Name <ceo-impostor@external-domain.com> where the external domain has valid SPF and DKIM. This passes all authentication checks. Inbox providers attempt to detect this via machine learning, but it remains effective against users who don't inspect the full From address. User education is the primary control here.
Here's the sneaky one. Even with perfect DMARC, scammers can set their display name to your organisation's name but use a completely different email address. Most email apps show the display name but hide the actual email. Your staff sees "DigiHwy Certainty" and trusts it, but the actual address is something-dodgy@random-domain.com. Always check the actual email address, especially if they're asking you to transfer money or give passwords.
What good email clients look for
Gmail, Outlook, and Apple Mail all have built-in protections that flag suspicious emails. They check whether the email passed the security checks, whether the sender's address looks unusual, and whether the email contains known spam patterns. A large padlock or warning banner in your inbox is a sign the email failed these checks.
Modern inbox providers evaluate: DMARC alignment (SPF + DKIM), domain reputation, sending IP reputation, BIMI (Brand Indicators for Message Identification, requires DMARC enforcement), engagement history, content signals, and link safety. Gmail displays a "?" avatar for unauthenticated senders. Outlook marks external senders with warning banners. Apple Mail surfaces DKIM/DMARC failure notices. These signals are increasingly prominent as providers tighten sender requirements.
Gmail, Outlook, and Apple Mail all try to protect you. They check if the email passed SPF, DKIM, and DMARC. They look at the sender's reputation. They scan for known spam patterns and dodgy links. If something fails, you'll see a warning banner or a question mark instead of the sender's photo. If you see these warnings, treat the email like a stranger offering you free durian - don't simply trust.
Protecting your organisation
The best protections are technical (DMARC with a strict policy) and human (training your team to check sender addresses carefully, never act on urgent requests via email alone, and verify unexpected payment or account requests through a second channel). Assume that any email claiming to be from someone inside your organisation — asking for money, credentials, or urgent action — could be faked.
Enforce DMARC at p=reject to prevent your domain from being spoofed outbound. For inbound protection: enable advanced phishing and spoofing controls in Google Workspace/Microsoft 365, deploy external sender labelling, train staff on BEC patterns (CEO fraud, invoice fraud), and establish out-of-band verification procedures for financial or access-related requests. Consider BIMI to help recipients visually verify legitimate mail from your domain.
Two things you need: technical protection and human protection. Technical: set DMARC to reject so nobody can fake your domain. Human: train your team to always check the actual sender address, never act on urgent money requests by email alone, and verify any unusual requests through a second channel (like picking up the phone). If someone emails you asking for urgent payment, verify first. Every time.
Quick Checklist
Here's a simple checklist for any organisation that wants to make sure their email is set up correctly and unlikely to land in spam.
A baseline deliverability and security checklist for organisational mail infrastructure.
Here's your "make sure I don't kena" checklist. Go through this, tick everything off, and your email setup will be solid. Skip any of these, and you're playing Russian roulette with your deliverability.
A DNS TXT record listing your authorised mail senders.
Publish a v=spf1 TXT record at your root domain listing all authorised sending sources and ending with -all (hard fail) or ~all (soft fail). Avoid +all.
The DNS record that says "these are the only servers allowed to send email from my domain." If you haven't set this up, do it now. Right now. I'll wait.
Your mail provider signs every email with a digital signature. Enable this in your Google Workspace or Microsoft 365 admin panel.
Generate DKIM keys in your mail provider's admin console and publish the public key as a DNS TXT record at the designated selector subdomain (e.g. google._domainkey.yourorg.org).
The digital signature that proves your emails are legit and haven't been tampered with. Enable this in your Google Workspace or Microsoft 365 admin panel. Takes five minutes.
Start with a monitoring-only policy so you can see who is sending email as you. Then tighten it once you've confirmed all legitimate senders are passing.
Publish a _dmarc TXT record starting with p=none and a rua= reporting address. Monitor reports (via Cloudflare DMARC Management or a third-party aggregator) before moving to p=quarantine then p=reject.
Start with monitoring mode so you can see what's happening. Then once you've confirmed everything's working, crank it up to reject. Like setting up CCTV first before hiring the security guard.
info@, billing@, and support@ are group inboxes — not tied to one person's account.
Use Google Groups collaborative inboxes or Microsoft 365 shared mailboxes for role addresses. No additional licences required.
info@, billing@, and support@ should be group inboxes. Not tied to one person. Not requiring separate licences. If you're still paying for individual seats for role addresses, you're burning money.
If you have a WordPress site that sends emails, configure it to use a proper mail delivery service via SMTP.
Install FluentSMTP or WP Mail SMTP and configure with a transactional mail provider. Verify DKIM and SPF pass in email headers after setup.
If you have WordPress and it's still using PHP mail, please go fix it now. Install FluentSMTP, connect to Brevo or similar. Your contact form submissions will actually reach your inbox. Revolutionary concept, I know.
Password resets and confirmations go through a transactional mail service. Newsletters and campaigns go through a dedicated bulk mail platform.
Separate sending infrastructure, dedicated subdomains, and distinct DKIM selectors for transactional vs bulk streams.
Password resets on one system, newsletters on another. Don't mix them. If your newsletter gets spam complaints, your password resets still work. Separation of concerns - good for code, good for email.
Your team knows to check the actual sender address, not just the display name, and to verify urgent or unusual requests through a separate channel.
User awareness training covering BEC, display name spoofing, and out-of-band verification procedures for financial or credential-related requests.
Your team knows to check the actual sender address, not just the display name. They know not to click links in urgent payment requests. They verify unusual requests through a second channel. If your staff click every link they receive, no amount of technical setup will save you.
Checking & Diagnosing Your Setup
Once you've configured SPF, DKIM, and DMARC, how do you know it's actually working? Free online tools like MXToolbox let you check your domain's email configuration in seconds — no technical background needed. Think of it as a health check for your email setup.
After publishing DNS authentication records, validation is essential. MXToolbox provides a suite of free lookup tools — SPF, DKIM, DMARC, and blacklist checks — that query your domain's DNS in real time and report misconfigurations, syntax errors, and reputation issues. These should be run after any configuration change and periodically thereafter.
OK so you've set up SPF, DKIM, and DMARC. But how do you know it's actually working? You don't just install a smoke alarm and never test it right? MXToolbox is like a free health check for your email setup - punch in your domain name, and it tells you exactly what's working and what's broken. No need to guess.
Blacklist Check
A blacklist check tells you if your domain or mail server's internet address has been flagged by any of the major spam blocklists. If you're on one, your emails may be rejected or sent to spam by many providers. MXToolbox checks dozens of blocklists at once — just enter your domain and it shows your status on each one. If you are listed, most blocklists have a removal request process you can follow.
MXToolbox's Blacklist Check (mxtoolbox.com/blacklists.aspx) queries 80+ DNS-based blocklists (DNSBLs) against your domain's MX record IPs. A listing on any major DNSBL — Spamhaus, Barracuda, SORBS, etc. — can cause widespread delivery failures. If listed, identify the root cause (compromised account, misconfigured relay, inherited IP reputation), remediate, and submit a delisting request through the blocklist's removal process.
Ever wonder if your domain has been blacklisted? MXToolbox checks over 80 blocklists at once. Just type your domain, hit enter, and pray for green ticks. If you see red, it means some blocklist has flagged your domain — maybe because of spam from a previous owner, a compromised account, or bad neighbours on your shared hosting. Most blocklists let you request removal, but you need to fix the root cause first or you'll just get listed again.
SPF Check
The SPF lookup tool reads your domain's SPF record and checks whether it's valid. It shows you exactly which servers are listed as authorised senders, flags any syntax errors, and warns you if your record is too long or includes too many lookups (there's a limit of 10). If your SPF is broken, your emails may fail authentication even though you thought everything was configured.
MXToolbox SPF Record Lookup parses and validates your v=spf1 TXT record. It checks for: syntax correctness, DNS lookup count (must not exceed 10 per RFC 7208), void lookup limits, nested include depth, presence of conflicting mechanisms, and whether the record terminates with an appropriate qualifier (-all, ~all). It also resolves all include: and ip4:/ip6: mechanisms to show the full list of authorised sending IPs.
SPF records have rules — like a maximum of 10 DNS lookups. Exceed that, and your SPF silently breaks. MXToolbox reads your SPF record and tells you: "Here are your authorised servers. Here's how many lookups you're using. And here's what's wrong." It's like getting a report card for your DNS. If you see errors, fix them before your emails start bouncing.
DKIM Check
The DKIM lookup verifies that your domain has a valid DKIM public key published in DNS. You'll need to know your DKIM "selector" — this is usually something like google for Google Workspace or selector1 for Microsoft 365. Enter your domain and selector, and the tool confirms whether the key is published, valid, and the right length. If nothing shows up, DKIM isn't set up yet.
MXToolbox DKIM Lookup queries the TXT record at <selector>._domainkey.<domain>. It validates the record format, key type (RSA), key length (minimum 1024-bit, 2048-bit recommended), and flags common issues like missing records, malformed base64, or multiple conflicting keys. Each mail provider uses its own selector — google for Google Workspace, selector1/selector2 for Microsoft 365, provider-specific selectors for transactional services like Brevo or SendGrid.
DKIM check is simple: enter your domain and your DKIM selector, and MXToolbox tells you if your DKIM key is published and valid. "What's a selector?" I hear you ask. It's the name tag for your DKIM key — Google Workspace uses google, Microsoft 365 uses selector1. If MXToolbox can't find your key, DKIM isn't set up. Go back to your email provider's admin panel and enable it.
DMARC Check
The DMARC lookup reads your domain's DMARC policy and checks whether it's correctly configured. It shows your current policy (none, quarantine, or reject), your reporting addresses, and any errors in the record. If you have no DMARC record at all, the tool tells you — and that means your domain has no policy for handling spoofed emails.
MXToolbox DMARC Lookup queries the TXT record at _dmarc.<domain> and validates: policy tag (p=), subdomain policy (sp=), alignment modes (adkim=, aspf=), reporting URIs (rua=, ruf=), percentage tag (pct=), and failure reporting options (fo=). It flags common misconfigurations such as missing rua, p=none without a reporting address (which provides no value), and syntax errors that cause the entire record to be ignored.
Type your domain into MXToolbox's DMARC check and it tells you: what's your policy? Do you have reporting set up? Are there any errors? If there's no DMARC record at all, that's a problem — it means anyone can spoof your domain and there's no policy telling receiving servers to do anything about it. It's like having a "no security cameras" sign on your building.
Full Email Health Check
MXToolbox also has an all-in-one "SuperTool" that checks your domain's email setup in one go — MX records, SPF, DKIM, DMARC, blacklists, and more. For a hands-on test, you can also use mail-tester.com: send a real email to the address they give you, and they score your message out of 10, telling you exactly what's helping and hurting your deliverability.
MXToolbox SuperTool (mxtoolbox.com/SuperTool.aspx) runs a composite diagnostic: MX record resolution, SPF validation, DKIM lookup (requires selector), DMARC policy check, reverse DNS, SMTP banner verification, and multi-DNSBL blacklist sweep. For end-to-end deliverability testing, mail-tester.com accepts a test email and returns a composite score evaluating: authentication (SPF/DKIM/DMARC), content analysis (SpamAssassin score), blacklist status, and message formatting. Both tools are free for basic use.
Want the full picture? MXToolbox SuperTool checks everything at once — MX records, SPF, DMARC, blacklists, the whole lot. But for the ultimate test, try mail-tester.com: they give you an email address, you send a real email to it, and they score your message out of 10. It tells you exactly what passed, what failed, and what's dragging your score down. Very satisfying when you get 10/10. Very humbling when you get 3/10.
Need Help Setting This Up?
Email configuration can be tricky to get right. DigiHwy Certainty offers free tech advisory for social and community organisations — we can help you review your DNS records, configure DMARC, or sort out your WordPress mail setup.
Get Free Advisory →