Email Deliverability Support NZ

What we check first

Deliverability problems are rarely fixed by random settings changes. The first job is to gather the ground truth: where DNS is hosted, what records exist today, and what the sender is actually doing.

DNS control points

Registrar and nameserver checks, who can change records, and how long propagation is likely to take.

SPF, DKIM, and DMARC basics

Confirm the basics are present and consistent with the platforms you actually send from (e.g. Microsoft 365 or Google Workspace).

Mailbox vs sending-domain issues

Separate login/permission problems from sending reputation or authentication failures.

What you get

The aim is a deliverability path that is reversible, auditable, and easy for a provider or a future admin to follow.

Record of current DNS records and what changed.
Clear next steps: fix DNS, fix mailbox, or escalate to provider with evidence.
Handover notes that reduce repeat incidents when staff or providers change.

Diagnostic flow

Separate authentication, reputation, and mailbox problems

Email problems can look similar from the outside. A message landing in spam, a rejected message, and a mailbox that cannot send are different failure modes. Treating them as one vague problem usually creates more DNS churn.

Authentication

Check whether SPF, DKIM, and DMARC line up with the real sending services, including websites, CRMs, invoicing tools, and newsletters.

Reputation and content

Look for sudden volume changes, compromised accounts, suspicious forwarding, or message patterns that explain why mail is being treated differently.

Mailbox and provider state

Confirm whether the mailbox can authenticate, whether sending is blocked, and whether provider-side logs or alerts explain the symptom.

Handover notes worth keeping

Registrar, DNS host, mail provider, and admin contact for each domain involved.
Current MX, SPF, DKIM, and DMARC records with the reason each record exists.
Known third-party senders such as website forms, accounting tools, CRMs, booking systems, or newsletter platforms.
Recent changes, bounce examples, timestamps, recipient domains affected, and whether the issue affects all mail or one sender.
Rollback notes for any DNS change so the next admin can understand what was altered.

Email authentication order

The safest sequence is to identify every legitimate sender first, then check SPF, DKIM, and DMARC against that sender list. Deliverability work gets messy when DNS is tightened before website forms, accounting tools, newsletter platforms, CRM systems, helpdesk tools, and Microsoft 365 or Google Workspace are all accounted for.

1. Sender inventory

List every system that sends mail for the domain, including people, shared mailboxes, website forms, invoices, booking tools, and marketing platforms.

2. SPF alignment

Check that SPF authorizes the real sending platforms without creating duplicate SPF records or leaving abandoned services in place.

3. DKIM signing

Confirm DKIM is enabled where the sending platform supports it, not just that a DNS record exists.

4. DMARC policy

Use DMARC reporting to understand legitimate mail flow before moving toward stricter policies that could block real business mail.

Bounce and spam-folder evidence

A bounce, spam-folder complaint, and missing message are different evidence types. A useful support pass keeps them separate: what was sent, from which platform, to which recipient domain, at what time, and what the receiving system said. That evidence helps decide whether the issue is authentication, reputation, content, mailbox policy, or a recipient-side rule.

Capture the full bounce text, not just the headline.
Record sender address, sending platform, recipient domain, timestamp, and message type.
Check whether only one platform fails, such as a website form or CRM, while normal mailbox mail works.
Check whether only one recipient domain is affected, such as Gmail, Outlook, a corporate gateway, or one customer.
Keep DNS changes and content/template changes separate so the cause is not hidden by several changes at once.

DMARC reporting and safe tightening

DMARC is most useful when it is treated as a visibility and policy tool, not a checkbox. An SME can start by collecting reports, identifying legitimate senders, fixing authentication gaps, and then deciding whether a stricter policy is appropriate. The goal is to reduce spoofing risk without accidentally blocking invoices, booking confirmations, or staff mail.

Monitor first

Start with reporting where appropriate so unknown legitimate senders can be found before stricter handling is applied.

Fix alignment gaps

DMARC depends on alignment. SPF or DKIM can pass technically while the visible From domain still fails alignment.

Segment senders

Consider subdomains for tools that send different mail streams, especially marketing, transactional mail, or website forms.

Record the policy owner

Document who receives reports, who reviews failures, and who is allowed to tighten or roll back the DMARC policy.

Maintenance handoff

Keep email fixes from becoming another undocumented change

Deliverability work is only durable when the next person can see what changed, which services are allowed to send, and when the records should be reviewed again. These routes turn a one-off fix into a cleaner operating baseline.

SME maintenance calendar

Schedule recurring SPF, DKIM, DMARC, sender inventory, renewal, and mailbox hygiene checks after the urgent issue is fixed.

Tools hub

Use practical launch, maintenance, and planning checklists to make future domain and email changes easier to audit.

SME tech checklist

Use the broader checklist when deliverability depends on domains, hosting, forms, Microsoft 365, phones, backups, or provider handover.

Remote IT support NZ

Use remote support when the next step is access checks, screenshots, reversible changes, or a provider-ready escalation note.

Email security and recovery reading path

Use the recovery path when deliverability problems appear after suspicious mailbox access, forwarding rules, or account compromise.

Domains, DNS, and email reading path

Use the broader DNS/email path when the issue crosses ownership, nameservers, routing, Microsoft 365 setup, or handover documentation.

Services hub

Use the services hub when the deliverability work reveals a wider support, website, DNS, Microsoft 365, or migration problem.

Official and primary references

Email authentication references worth checking

These references support the same deliverability workflow: authenticate legitimate senders, understand SPF, DKIM, and DMARC, and tighten policy only after real mail flow is understood.

Google Workspace authentication methods Google guidance covering SPF, DKIM, and DMARC for Workspace domains. Google email sender guidelines Current sender guidance for authentication and delivery expectations to Gmail users. Microsoft email authentication Microsoft guidance on SPF, DKIM, DMARC, and related authentication checks in Microsoft 365. Microsoft mail flow best practices Microsoft guidance noting MX, SPF, DKIM, and DMARC as important DNS components for mail flow. DMARC.org overview Primary DMARC overview explaining how DMARC builds on SPF and DKIM. Cloudflare SPF, DKIM, and DMARC explainer Practical explanation of how SPF, DKIM, and DMARC help authenticate email senders.

FAQ

Email deliverability questions

Deliverability work is safest when the DNS records, sending services, and escalation evidence are clear.

What records affect email deliverability?

MX, SPF, DKIM, and DMARC records are the common DNS control points for business email routing and authentication.

Why can a new website or CRM break email sending?

A website, CRM, booking tool, accounting platform, or newsletter system may send on behalf of the domain and need to be included correctly in authentication records.

What evidence helps with deliverability escalation?

Useful evidence includes bounce text, timestamps, affected recipient domains, sending platform, current DNS records, recent changes, and whether all mail or only one sender is affected.

Related context

Support pages and checklists that pair with deliverability work

Start with a checklist when you need structure, then use the deeper service pages when the issue crosses into routing or platform configuration.

DNS and email checklist A practical checklist for business email control points, records, and handover hygiene. SME tech checklist A broader checklist for websites, domain email, Microsoft 365, VoIP, DNS, backups, and support documentation. Email security reading path Recovery stages, persistence checks, and evidence notes when deliverability follows mailbox compromise. Domains and DNS reading path Domain ownership, DNS hosting, website routing, and email delivery in one structured path. Microsoft 365 support NZ When the issue is actually account access, admin controls, or platform configuration. Microsoft 365 setup Christchurch Use this when the deliverability issue sits inside a new, inherited, or undocumented Microsoft 365 tenant setup. IT support and Microsoft 365 reading path A wider route for identity, MFA, device, mailbox, remote support, and tenant handover checks. DNS and routing support Deeper technical notes when the symptom crosses into routing, nameservers, or propagation edge cases. New Zealand profile National context for remote support and broader NZ queries. Christchurch profile Local context and Christchurch entity/profile asset. Services hub Entry points for distinct IT support and connectivity intents.