When your business sends an invoice, password reset, booking confirmation or customer update, the recipient needs to know that the message genuinely came from you. Email providers also need a way to distinguish legitimate messages from attempts to impersonate your domain.
SPF, DKIM, DMARC provide that verification. They are three email authentication methods configured through your domain’s DNS records. Each performs a different job, but they work together to help receiving mail systems assess whether a message can be trusted.
SPF checks whether a sending service is authorised to send mail for your domain. DKIM adds a cryptographic signature that helps confirm a message hasn’t been altered during delivery. DMARC checks whether the authenticated domain matches the domain shown to the recipient and tells receiving systems what to do when authentication fails.
For Australian small businesses, sole traders, online stores and teams managing several email platforms, getting these records right can reduce domain spoofing, support legitimate email delivery and provide better visibility into who is sending mail using your domain.
How SPF, DKIM and DMARC Work Together
SPF, DKIM and DMARC are three email authentication methods that work together rather than competing with one another. Each checks a different part of the sending process, helping receiving mail servers decide whether a message is likely to be legitimate.
When an email arrives, the receiving server can look up the DNS records published for the sender’s domain and compare them with information contained in the message.
SPF Checks the Sending Source
Sender Policy Framework, or SPF, checks whether the server or service that sent the email is authorised to send on behalf of the domain name.
A business may send mail through several platforms, including Microsoft 365, Google Workspace, a website form, an ecommerce platform, accounting software or a newsletter service. These approved sending sources need to be represented correctly in the domain’s SPF record.
When a receiving mail server performs an SPF check, it compares the sending source with the SPF policy published in DNS. If the source isn’t authorised, the message can fail SPF.
SPF doesn’t confirm the visible From address on its own, which is one reason DMARC is also used.
DKIM Checks the Message Signature
DomainKeys Identified Mail, or DKIM, uses cryptographic signing to help verify a message.
When an authorised email platform sends a message, it adds a DKIM signature. A matching public key is published in DNS, allowing the receiving mail server to verify that the message was signed correctly and that the signed parts of the message weren’t altered after signing.
A business can use multiple DKIM records because different sending platforms can have their own selectors. For example, Microsoft 365 and a separate marketing platform may each use their own DKIM configuration.
DMARC Checks Alignment and Applies a Policy
Domain-based Message Authentication, Reporting and Conformance, or DMARC, brings SPF and DKIM together.
DMARC checks whether the domain authenticated by SPF or DKIM aligns with the domain shown in the visible From address. It then applies the policy published by the domain owner.
Depending on the policy, receiving mail systems may be told to:
- Monitor messages that fail authentication
- Treat failed messages with suspicion, often by sending them to spam
- Reject messages that fail DMARC
DMARC can also provide reporting, which helps domain owners see which services are sending mail on their behalf and whether those messages are authenticating correctly.
Together, SPF checks the sending source, DKIM checks the message signature and DMARC checks whether the authenticated identity matches the domain the recipient sees. Using all three gives receiving mail systems a clearer basis for assessing legitimate business email.
Why Email Authentication Matters for Australian Businesses
Business email often carries information that customers act on quickly.
A customer might receive an invoice, reset a password, follow a booking link or respond to an account notice. If somebody impersonates your domain, the fraudulent message can look far more convincing than one sent from an unrelated address.
SPF, DKIM and DMARC help receiving systems identify legitimate mail and detect suspicious sending activity.
Reduce Domain Spoofing
Email spoofing occurs when a sender makes a message appear as though it came from a domain or address they’re not authorised to use. Authentication records make that impersonation harder to pass off as legitimate.
SPF can identify a sending system that hasn’t been approved. DKIM can provide evidence that a recognised platform signed the message. DMARC checks alignment and provides a policy for messages that fail.
No single record stops every form of email abuse, but together they give receiving systems much better information for assessing messages sent in your name.
Support Legitimate Email Delivery
Authentication also helps receiving providers distinguish legitimate business email from suspicious ones.
That matters when your organisation sends through several platforms. A business might use Microsoft 365 for staff email, an ecommerce system for order notifications, an accounting service for invoices and another provider for newsletters.
If those systems aren’t configured correctly, genuine messages may fail authentication.
Creating an inventory of all sending services before making DNS changes can prevent legitimate systems from being overlooked.
Understand Who Is Sending Mail from Your Domain
DMARC reporting can reveal systems your team has forgotten about.
A report might expose:
- An old newsletter platform
- A legacy website
- A third-party booking service
- A previous accounting tool
- A new marketing platform that was added without DNS changes
- Unauthorised attempts to impersonate the domain
This visibility is particularly useful for growing businesses where responsibility for email may be divided between owners, marketing staff, developers and IT providers.
The clearer your sender inventory is, the easier it becomes to keep authentication accurate.
Set up SPF for Approved Sending Sources
Your SPF record identifies services permitted to send email for a domain.
Before changing it, list every legitimate sending platform. Don’t focus only on staff email.
Your list may need to include website servers, contact forms, Microsoft 365, Google Workspace, accounting systems, CRM tools, support software, online stores and newsletter platforms.
Use One SPF Record Per Domain
A domain should publish one SPF TXT record.
If several providers send mail for the same domain, their required mechanisms should normally be combined into that single SPF policy rather than published as separate SPF records.
Multiple SPF TXT records for the same domain can cause a permanent SPF error.
A provider may instruct you to add an include: mechanism. A server sending directly may require an ip4: or ip6: mechanism.
Follow the current instructions supplied by each provider rather than copying values from an unrelated domain or an old setup.
Understand SPF Policy Endings
SPF records commonly finish with a mechanism that describes what should happen with sources not otherwise authorised.
~allas a soft-fail approach that may suit a period where older or less obvious senders are still being identified.-allas a firmer instruction once all legitimate sending systems have been confirmed.+allas something to avoid because it effectively permits any server to send on behalf of the domain.
Don’t tighten the policy before you understand every service sending legitimate mail.
Watch the SPF DNS Lookup Limit
SPF evaluation has a limit of 10 DNS-based lookups. Adding many third-party services can cause a policy to exceed that limit. When that happens, receivers may be unable to evaluate SPF record properly.
After publishing or changing your record, use an SPF checker and verify that:
- The syntax is valid
- Provider includes resolve correctly
- All approved sources are represented
- The record remains within the lookup limit
- Retired platforms have been removed when appropriate
Keep notes whenever a sending service is added or removed. That reduces the risk of somebody deleting a mechanism later without understanding why it was there.
Configure DKIM for Each Email Platform
DKIM is configured differently from SPF. Rather than maintaining one combined record, separate email providers can publish their own DKIM records using different selectors.
A DKIM selector identifies the signing configuration used by a particular service. A provider may give you a hostname that follows a structure similar to:
selector._domainkey.example.com.au
The exact format varies by provider.
Some platforms ask you to publish a TXT record containing the cryptographic verification information. Others use a CNAME that points to DNS managed by the email provider. Follow the exact record type and values supplied by the platform you’re configuring.
Don’t Remove Existing DKIM Records without Checking
Adding a new provider doesn’t usually mean replacing an existing DKIM selector. Different active platforms may need separate DKIM records.
For example, a company might have one selector for Microsoft 365 and another for its newsletter provider. Removing one because a new record was supplied could cause an existing platform to stop authenticating properly.
Keep a simple record of what each selector belongs to.
Test DKIM After DNS Changes
Once the DNS change has had time to propagate (this usually takes 2-8 hours), send a test message from the platform you configured.
Review the message authentication results and look for a successful DKIM result.
If it fails, check:
- The selector
- The DNS record type
- The hostname
- The copied DNS value
- Whether the sending platform has DKIM signing enabled
- Whether DNS propagation has completed
If the provider supplies a validation tool, use it to confirm that the DNS record can be found. Repeat the process for every service that sends mail for your business.
Add DMARC and Introduce Enforcement Gradually
Once SPF and DKIM are working, DMARC gives you a way to monitor authentication and decide how receiving mail systems should handle failures.
A DMARC record is normally published at a DNS hostname beginning with _dmarc.
Before enforcing a strict policy, make sure you understand every service that sends email using your domain.
DMARC Depends on Alignment
DMARC doesn’t simply ask whether SPF or DKIM produced a successful technical result. It checks whether the authenticated identity aligns with the domain shown in the visible From address. That distinction matters.
A message may technically pass SPF because a third-party provider is authorised for its own sending domain, but DMARC can still fail if that identity doesn’t align with the From domain.
The same principle applies to DKIM.
Start with Monitoring
A common starting DMARC policy is:
p=none
This tells participating receiving systems to monitor authentication results without asking them to quarantine or reject failed messages.
DMARC can also include an address for aggregate reports using the rua tag.
Those reports can help you identify:
- Which systems send mail for the domain
- Which services pass authentication
- Where SPF or DKIM configuration needs attention
- Whether alignment is working
- Unexpected or suspicious sending activity
A DMARC record generator can help format a record, but it can’t know every legitimate service used by your organisation. You still need an accurate understanding of your own sending environment.
Move Towards Enforcement Carefully
After reviewing reporting and confirming that legitimate email is authenticating correctly, you can consider stronger policies.
p=quarantine asks receiving providers to treat failed messages with suspicion. In many cases, that means directing them towards spam or junk folders.
The pct tag can be used to apply a policy to a percentage of affected mail, allowing enforcement to be introduced gradually.
A stronger policy is:
p=reject
This asks participating receiving systems to reject messages that fail the DMARC requirements.
Moving directly to reject without first understanding your legitimate senders can cause genuine mail from overlooked platforms to be blocked.
Continue reviewing your setup after enforcement begins. Adding a new marketing tool, changing an invoicing system or rebuilding a website can introduce another sending source.
Test Authentication and Fix Common Problems
Publishing DNS records is only part of the job. You also need to confirm that real messages authenticate as expected.
An SPF, DKIM and DMARC checker can help verify whether records are visible and correctly formatted, but testing actual messages gives you another layer of information.
Send test messages from every approved platform.
Then inspect the message headers or authentication results.
You ideally want to see results showing:
- SPF passes for the sending service
- DKIM passes using the intended signing domain
- DMARC passes because SPF or DKIM aligns correctly with the visible From domain
Common SPF Problems
One common issue is an incomplete SPF record.
A business may configure Microsoft 365 correctly but forget that its website, newsletter system or accounting platform also sends mail using the domain.
Another common problem is publishing two separate SPF records.
Other issues can include:
- Incorrect provider mechanisms
- Old sending services that remain authorised unnecessarily
- Exceeding the SPF DNS lookup limit
- Typing errors
- Publishing the record under the wrong hostname
Review the full list of sending sources whenever SPF fails.
Common DKIM Problems
A DKIM failure often comes down to configuration.
Check whether:
- The correct selector has been published
- The DNS record matches the current provider instructions
- The sending service has signing turned on
- The hostname is correct
- A long DNS value was copied without missing characters
- The DNS change has finished propagating
If several services send email, test each one individually because one working DKIM record doesn’t confirm that every platform is configured.
Common DMARC Problems
A message can pass SPF or DKIM and still fail DMARC. This often happens because the authenticated domain and the visible From domain don’t align.
Another issue is enforcing too aggressively before all sending systems have been identified.
DMARC reports may reveal mail from a legitimate application nobody included during the initial setup. Treat that information as a reason to investigate the sender rather than immediately blocking it.
Once you confirm what the service is, either configure it correctly or stop it from sending as the domain if it’s no longer required.
Allow for DNS Propagation
DNS changes may not be visible everywhere immediately.
How long propagation takes depends partly on the DNS provider and the record’s time-to-live setting.
If you have just published a record, allow time before deciding it’s broken.
Maintain Your Email Security as Your Business Changes
Email authentication isn’t a one-time setup.
Businesses change systems regularly. A team might switch accounting software, adopt a new CRM, move newsletters to another provider or replace a website platform.
Each change can affect your DNS records.
Maintain an inventory of authorised sending sources and update it whenever a service is added or removed.
It also helps to assign responsibility for approving DNS changes. If marketing staff, developers and external providers can all introduce new sending tools without coordination, authentication settings can quickly become difficult to manage.
Review DMARC Reporting
DMARC reports can continue to provide useful information after your policy reaches quarantine or reject.
Review them periodically for:
- New sending sources
- Increasing authentication failures
- Old platforms that still send mail
- Changes in alignment
- Suspicious attempts to use the domain
If legitimate mail suddenly starts failing, check for recent platform, DNS or website changes.
Keep Access to DNS Restricted
Email authentication depends on accurate DNS.
Limit access to people who genuinely need to make changes, and review permissions when staff, developers or agencies stop working with the business.
Use strong, unique passwords and multi-factor authentication where your DNS or email provider supports it.
Know Where to Ask for Help
Your email provider is usually the best source for the exact SPF and DKIM values its service requires. Your DNS provider can help you locate the correct DNS management area and identify whether records have been entered in the intended place.
VentraIP offers locally based support for Australian customers, with technical topics explained in plain language rather than unnecessary jargon.
VentraIP customers can manage DNS records through their domain services and seek local technical support when they need help understanding where a record belongs or whether a DNS configuration has been entered correctly. The sending provider should still be treated as the source for the specific values required by its platform.
If you manage several email services, keep a written record of every provider and its authentication setup. That small amount of documentation can save a lot of troubleshooting when something changes later.
Frequently Asked Questions
What Are SPF, DKIM and DMARC?
SPF, DKIM and DMARC are three email authentication methods used to help receiving mail systems verify messages sent using your domain.
SPF identifies approved sending sources. DKIM adds a cryptographic signature that helps confirm a message hasn’t been altered after signing. DMARC checks alignment between authenticated identities and the visible From domain, then applies the domain owner’s policy when authentication requirements aren’t met.
Do Australian Small Businesses Need SPF, DKIM and DMARC?
Any business that regularly sends customer or staff email can benefit from properly configured authentication.
That includes organisations sending:
- Invoices
- Password resets
- Booking confirmations
- Order updates
- Support messages
- Staff email
- Marketing campaigns
These DNS-based controls help receiving mail systems assess whether messages using your domain are legitimate and can reduce the risk of domain spoofing.
Can I Have Multiple SPF Records for One Domain?
No. A domain should publish one SPF TXT record.
If several platforms are authorised to send email, their required mechanisms should be combined into the one SPF policy. Publishing multiple SPF records can result in an SPF permanent error.
Can I Have Multiple DKIM Records?
Yes.
Different email providers can use separate DKIM selectors, allowing several DKIM records to coexist for the same domain.
Don’t delete an existing selector unless you have confirmed that no active service is still using it.
Does DMARC Require Both SPF and DKIM to Pass?
No. DMARC can pass when either SPF or DKIM passes and the successful authentication aligns correctly with the visible From domain.
Having both configured provides two authentication paths and can make your setup more resilient when different sending services behave differently.
Why Can SPF Pass While DMARC Fails?
SPF and DMARC test different things. SPF can confirm that the sending system is authorised for a particular envelope sender domain. DMARC also asks whether that domain aligns with the domain shown in the visible From address. If those domains don’t align, the message may pass SPF while failing DMARC.
Should I Start DMARC With p=reject?
Usually not. Starting with p=none allows you to gather reporting and identify legitimate senders without asking receiving systems to block failed messages.
Once valid mail is consistently authenticating and aligning correctly, you can move towards quarantine and then reject where appropriate.
How Do I Check SPF, DKIM and DMARC?
Use an authentication checker to confirm that your DNS records are published, then send test messages from each authorised platform.
Inspect the authentication results for SPF, DKIM and DMARC rather than testing only one sending service.
If something fails, compare the result with the latest setup instructions from the email provider and confirm that the correct DNS record was published.
How Long Do DNS Changes Take?
DNS updates can sometimes become visible quickly, but propagation varies according to the DNS provider and the record’s TTL.
Allow time before retesting a newly published record. After propagation, send messages from each approved platform and verify that the expected authentication checks pass.
Can SPF, DKIM and DMARC Stop Every Malicious Email?
No. They help receiving systems verify messages that use your domain, but they don’t replace other security practices.
Continue using strong passwords, multi-factor authentication where available, controlled account access and regular reviews of your email and DNS configuration.
For Australian businesses managing domains, hosting and business email, keeping authentication records accurate is an important part of protecting customer communications.
Manage your DNS carefully, follow the setup instructions from each sending provider and review your authentication results whenever your email systems change. VentraIP customers can contact the local support team for help with DNS management and hosting-related configuration.
Set Up Business Email You Can Trust
Your customers rely on your emails for invoices, bookings and important updates. Correctly configured SPF, DKIM and DMARC help protect your domain from impersonation and give receiving providers greater confidence in the messages you send.
Give your business a professional email address that matches your domain, backed by VentraIP’s Australian support team. Whether you’re setting up your first mailbox or moving an existing business email service, we can help you get started and provide guidance on your email and DNS configuration.
Set up your business email with VentraIP and make every customer conversation feel more professional.
