InboxWizards

Let’s Talk

Author: Anthony Mitchell

  • Emails Going to Junk in Outlook or Hotmail? A Guide for UK & Irish Senders

    Emails Going to Junk in Outlook or Hotmail? A Guide for UK & Irish Senders

    Your emails reach Gmail inboxes without trouble, but anyone on Outlook, Hotmail or Live says they found you in junk. It’s one of the most common problems we see from businesses in the UK and Ireland, and Microsoft’s filtering works differently enough from Gmail’s that the usual fixes don’t always carry across.

    Here’s the checklist we work through when a client’s mail is going to junk at Microsoft, in the order that usually finds the problem fastest.

    Why Microsoft matters so much in the UK and Ireland

    A big share of UK and Irish personal email addresses sit with Microsoft: hotmail.co.uk, live.co.uk, live.ie, outlook.com, msn.com and the rest. Plenty of people set up a Hotmail address years ago and never moved. If you sell to consumers, the Microsoft domains are often one of the biggest groups on your list after Gmail.

    It matters for B2B too. Lots of UK and Irish businesses, charities and public bodies run their email on Microsoft 365. Their mail goes through Microsoft’s filtering as well, and their IT team can add stricter rules on top. So when a quote, an invoice or a sales email “never arrived”, Microsoft is often where it went missing.

    Quick check: sort your list by domain and add up the Microsoft ones. That tells you how much of your email (and your revenue) depends on getting this right.

    First: junk or rejected?

    These are two different problems. If your email bounces with an error like 550 5.7.515 Access denied, Microsoft is refusing it outright because authentication failed. Our guide to fixing 550 5.7.515 covers that. If the email arrives but lands in the Junk Email folder, Microsoft accepted it but didn’t trust it enough for the inbox. That’s what this checklist is for.

    1. Authentication: SPF, DKIM and DMARC all passing and aligned

    Since May 2025 Microsoft has required SPF, DKIM and DMARC from high-volume senders to Outlook.com, Hotmail and Live addresses. Even below that volume, mail that fails authentication is far more likely to be junked.

    • Send a test to an Outlook.com address you own and check the headers for spf=pass, dkim=pass and dmarc=pass.
    • Make sure DKIM is signed with your domain, not your email platform’s. Why DKIM fails covers the usual causes.
    • Check you have exactly one SPF record, within the 10-lookup limit.

    2. Sending IP and domain reputation

    Microsoft weighs the reputation of the IP address your mail comes from heavily. If you send from a dedicated IP, register it with Microsoft’s Smart Network Data Services (SNDS), which shows how Outlook.com sees that IP, including complaint rates and spam-trap hits. If you’re on a shared IP through an email platform, your platform manages this, but a sudden drop in placement across all your mail can point to a shared-IP problem worth raising with them.

    Alongside SNDS, sign up to Microsoft’s Junk Mail Reporting Program (JMRP). It sends you a report each time an Outlook.com, Hotmail or Live user marks one of your emails as junk, so you can take them off your list before the complaints pile up. JMRP feeds are now linked to your SNDS account, and since early 2026 the reports no longer include the email body, so add a campaign reference to your headers if you want to know which send caused the complaint. On a shared IP, your email platform usually handles this for you.

    Also check your domain and IPs against the main blocklists. A listing doesn’t always cause junking at Microsoft, but it’s a strong warning sign.

    3. Complaints: people clicking “Report junk”

    Every time an Outlook user marks your email as junk, it counts against you. Common causes:

    • Emailing people who didn’t clearly sign up, or who signed up a long time ago and have forgotten you.
    • An unsubscribe link that’s hard to find, so people report you as junk instead.
    • Sending far more often than people expected when they signed up.

    Microsoft expects a working unsubscribe link in marketing email (and one-click unsubscribe from bulk senders), so make it easy to find.

    4. List hygiene

    Repeatedly sending to addresses that don’t exist tells Microsoft you aren’t maintaining your list. Remove hard bounces straight away, stop mailing people who haven’t opened or clicked in six to twelve months (or send them a short re-engagement campaign first), and never buy or rent lists. Old Hotmail addresses that have been closed are a common source of both bounces and spam traps.

    5. Consistent volume

    Microsoft is suspicious of sudden spikes. If you normally send 2,000 emails a week and suddenly send 40,000 to your whole database, expect a lot of it to land in junk. Build volume up gradually, especially from a new domain or IP. This is called warming.

    6. From and Reply-To addresses

    Use a real, recognisable From name and an address on your own domain that can receive replies. A noreply@ address on a domain that doesn’t match your website looks less trustworthy to filters and to people.

    7. Content and links

    Content matters less than reputation, but it still counts:

    • Avoid link shorteners and links to domains with poor reputation.
    • Keep a sensible balance of text and images. A single large image with little text is a classic spam pattern.
    • Make sure the domains in your links match the brand sending the email.

    8. Engagement

    Microsoft, like Gmail, notices whether people open, reply to and move your emails out of junk. Ask new subscribers to add you to their contacts, and focus regular sends on people who engage. Sending less to unengaged contacts often improves placement for everyone else.

    Test before you guess

    The quickest way to see where you stand is an inbox placement test: you send your campaign to a set of test mailboxes across Outlook, Hotmail, Gmail, Yahoo and corporate Microsoft 365, and see exactly where it lands. It turns “I think we’re going to junk” into a clear answer, and shows whether the problem is Microsoft-specific.

    Find out why you’re landing in junk

    Our deliverability audit runs inbox placement tests across Outlook, Hotmail, Gmail and Microsoft 365, checks your authentication and reputation, and gives you a prioritised list of fixes. Or start by checking your domain’s records free.

    Talk to an expert
    Check your domain free
  • Why DKIM Fails: 6 Common Causes and How to Fix Them

    Why DKIM Fails: 6 Common Causes and How to Fix Them

    DKIM is the part of email authentication that does the heavy lifting. It survives forwarding, it’s what most marketing platforms rely on to pass DMARC, and Google, Yahoo and Microsoft all expect it from bulk senders. So when your headers or DMARC reports show dkim=fail, it’s worth fixing quickly.

    Here are the six causes we see most often, how to spot each one and how to fix it.

    First, a 30-second refresher

    When you send an email, your platform adds a DKIM signature: a header with an encrypted fingerprint of the message, the signing domain (d=) and a selector (s=). The receiving server looks up the public key at selector._domainkey.yourdomain.co.uk and checks the fingerprint still matches. If the key can’t be found, or the message has changed since it was signed, DKIM fails. Our introduction to DKIM covers the basics in more detail.

    To find which cause you’re dealing with, open the full headers of a failing email and look at the Authentication-Results line. The wording after dkim=fail (or dkim=permerror) usually points straight at the problem.

    1. The DKIM record is missing or published in the wrong place

    What you’ll see: “no key for signature”, “key not found” or dkim=permerror.

    The receiving server went to look up your public key and found nothing. Usually one of these has happened:

    • The record was never added, or was added to the wrong domain.
    • The DNS panel added your domain to the name automatically, creating s1._domainkey.yourdomain.co.uk.yourdomain.co.uk.
    • The selector in the record doesn’t match the one in the signature (for example, s1 published but s2 used).

    Fix: Compare the s= and d= values in the email’s DKIM signature with the record in your DNS, and look the record up with a DKIM checker to confirm it resolves.

    2. DKIM was set up in DNS but never switched on

    What you’ll see: the email is signed by your platform’s domain instead of yours, or not signed at all.

    Most platforms make you add the DNS records and then click “verify” or “enable” in their settings. Microsoft 365 is the classic example: you publish two CNAME records (selector1._domainkey and selector2._domainkey) and then enable DKIM signing for the domain in the Defender portal. Skip that last step and Microsoft keeps signing with its own default domain.

    Fix: Go back into each platform’s domain authentication settings and confirm DKIM signing shows as active for your domain.

    3. The key has been broken by your DNS panel

    What you’ll see: “invalid public key”, “key syntax error” or dkim=permerror.

    DKIM keys are long. A 2048-bit key is over 400 characters, and a single DNS text string can only hold 255. Some DNS panels split long values automatically and some don’t. Copy-and-paste can also add stray spaces, line breaks or extra quotation marks, or cut off the end of the key.

    Fix: Republish the record exactly as your platform provides it. If your DNS panel struggles with long values, use the CNAME option many platforms offer instead. The platform then hosts the key and keeps it up to date.

    4. The email was changed after it was signed

    What you’ll see: “body hash did not verify” or “signature did not verify”.

    DKIM’s fingerprint covers the message body and key headers. If anything changes them on the way, the fingerprint no longer matches. Common culprits:

    • Email security gateways that rewrite links or add “external sender” banners
    • Mailing lists and Google Groups that add footers or change the subject line
    • Signature or disclaimer tools that add text after sending
    • Forwarding services that alter the message

    Fix: Make sure any tool that modifies outgoing mail does so before DKIM signing, not after. For mailing lists you don’t control, there’s little you can do. That’s normal, and it’s one reason DMARC passes if either SPF or DKIM passes and aligns.

    5. The key was rotated or removed

    What you’ll see: DKIM was passing and suddenly fails across all mail from one service.

    Platforms periodically switch to new keys, and people tidying DNS sometimes delete an “unrecognised” _domainkey record that was still in use. If a key is replaced before the platform stops using it, signatures fail until things catch up.

    Fix: Never delete a _domainkey record without checking your DMARC reports to see whether anything still signs with that selector. Where possible, use CNAME-based DKIM so the platform handles rotation for you. And check you’re on 2048-bit keys: Google recommends them, and some older setups still use weaker 1024-bit keys.

    6. DKIM passes, but not for your domain

    What you’ll see: dkim=pass in the headers, but DKIM shown as failing in DMARC reports.

    This one catches out a lot of people. DKIM can pass perfectly well for the platform’s own domain (for example d=platform-example.com). DMARC, though, only counts DKIM when the signing domain matches your From domain. That’s called alignment. Without it, DKIM is technically working but does nothing for your DMARC result or your sender reputation.

    Fix: Set up custom DKIM (often called “domain authentication” or “branded sending domain”) in every platform that sends as your domain, so the signature reads d=yourdomain.co.uk. This matters even more as you move your DMARC policy from p=none to enforcement.

    A quick DKIM health check

    • Every service that sends as your domain signs with d=yourdomain.co.uk.
    • Every selector in use has a working record in your DNS.
    • Keys are 2048-bit where the platform supports it.
    • Your DMARC reports show DKIM passing and aligned for all legitimate sources.

    Get your DKIM sorted

    DKIM problems are fiddly to track down across several platforms, and they quietly hold back your inbox placement until they’re fixed. Start by checking your domain’s records free, or let us find every service sending as your domain and set up aligned, 2048-bit DKIM for each one.

    Check your domain free
    Talk to an expert
  • Two SPF Records? Why It Breaks Your Email and How to Merge Them

    Two SPF Records? Why It Breaks Your Email and How to Merge Them

    Here’s a mistake that breaks email for thousands of businesses, and it usually starts with good intentions. You sign up for a new email platform, it tells you to “add this SPF record to your DNS”, and you add it. The problem is that you already had one.

    A domain can only have one SPF record. With two, SPF doesn’t check both and pick the best result. It fails completely.

    Why two SPF records break SPF

    The SPF standard (RFC 7208) is explicit: a domain must not publish more than one SPF record. When a receiving server looks up your domain and finds two TXT records that start with v=spf1, it returns a PermError (“permanent error”) and stops. Neither record is used.

    In practice that means:

    • Every email from your domain fails SPF, including your normal day-to-day email from Microsoft 365 or Google Workspace.
    • DMARC can only pass through DKIM. Any service that isn’t signing with DKIM for your domain will fail DMARC.
    • Emails to Outlook and Hotmail can be refused with 550 5.7.515 errors, and once your DMARC policy is quarantine or reject, failing emails go to spam or bounce.

    How to check if you have two SPF records

    Look at the TXT records on your root domain (the one shown as @ or left blank in most DNS panels). Count how many start with v=spf1. More than one means you have the problem.

    Common giveaways:

    • One record from your mailbox provider and a second added later by a marketing, CRM or helpdesk platform.
    • An old record left behind after moving from one email host to another.
    • A record added by your web host or domain registrar automatically, alongside the one you created.
    • A v=spf2.0 record (an old Microsoft “Sender ID” format). It isn’t a second SPF record in the same sense, but it’s obsolete and worth removing while you’re there.

    Our free checker reads your SPF record and flags this instantly. The link is at the end of this post.

    How to merge them into one

    Say you have these two records:

    v=spf1 include:spf.protection.outlook.com -all
v=spf1 include:_spf.your-email-platform.com ~all

    Merging them takes four steps.

    1. Keep one v=spf1 at the start

    Every SPF record starts with v=spf1, exactly once.

    2. Combine all the mechanisms in the middle

    Take every include:, ip4:, ip6:, a and mx from both records and list them once each, separated by spaces. Remove duplicates.

    3. Keep one all at the end

    Choose a single ending. ~all (soft fail) is the common choice while you’re setting things up, and -all (hard fail) is stricter. Don’t include both, and make sure all is the last thing in the record. Anything after it is ignored.

    4. Delete the old records and publish the merged one

    v=spf1 include:spf.protection.outlook.com include:_spf.your-email-platform.com ~all

    Publish this as the only SPF TXT record on your root domain, then delete the others.

    Before you merge: two things to check

    Do you still need every entry?

    Merging is a good moment to remove services you no longer use. It’s also worth checking whether a platform needs to be in your SPF at all. Many marketing platforms use their own bounce domain, so your SPF isn’t what they’re checked against. They pass DMARC through DKIM signed with your domain instead.

    Will the merged record go over 10 lookups?

    Combining two records often pushes you over SPF’s 10-lookup limit, which causes a different PermError. If that happens, our guide to fixing “too many DNS lookups” covers how to trim it back.

    What about subdomains?

    The one-record rule applies per domain name. yourdomain.co.uk and news.yourdomain.co.uk can each have their own SPF record. That’s a useful way to give a marketing platform its own SPF without touching the record your main email depends on.

    After you’ve fixed it

    • Wait for DNS to update (usually minutes, occasionally a few hours).
    • Re-check that exactly one v=spf1 record exists.
    • Send a test email from each service and check the headers show spf=pass.
    • Keep an eye on your DMARC reports for a week to confirm everything is passing.

    Check your SPF record in seconds

    Not sure how many SPF records your domain has? Our free checker reads your SPF, DMARC and BIMI records and flags duplicates straight away. If you’d rather someone just sorted it, we’ll merge your records, trim anything you no longer need and confirm every service still passes.

    Check your domain free
    Talk to an expert
  • How to Read a DMARC Aggregate Report (Without Losing Your Mind)

    How to Read a DMARC Aggregate Report (Without Losing Your Mind)

    You’ve set up DMARC with a rua= address, and now your inbox is filling with emails from Google, Microsoft, Yahoo and others, each with a zipped file attached. Inside is a wall of XML. This guide explains what those reports are, how to read one, and, most importantly, what to do with what you find.

    What a DMARC aggregate report is

    When you publish a DMARC record with a rua=mailto: address, mailbox providers send you a summary of all the email they received claiming to be from your domain. Each report usually covers one day from one provider and tells you:

    • which servers (IP addresses) sent email as your domain
    • how many messages each one sent
    • whether those messages passed SPF and DKIM, and whether they aligned with your domain
    • what the provider did with them under your policy

    Reports contain no message content and no recipient addresses, just counts and authentication results. They usually arrive as .xml.gz or .zip attachments with names like google.com!yourdomain.co.uk!1759276800!1759363199.xml.gz: the reporter, your domain, then the start and end of the reporting period as Unix timestamps.

    The anatomy of a report

    Here’s a trimmed-down example of what you’ll see once you unzip one:

    <feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>1234567890</report_id>
    <date_range><begin>1759276800</begin><end>1759363199</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.co.uk</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.25</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>yourdomain.co.uk</header_from></identifiers>
    <auth_results>
      <dkim><domain>yourdomain.co.uk</domain><selector>s1</selector><result>pass</result></dkim>
      <spf><domain>bounces.platform-example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

    It looks intimidating, but there are only four parts that matter.

    1. report_metadata: who sent the report

    The provider’s name (org_name), a report ID and the time period covered. Useful for knowing which mailbox provider’s view you’re looking at, and nothing more.

    2. policy_published: what your DMARC record said

    This shows the policy the provider found in your DNS: your domain, your policy (p) and the alignment modes (adkim and aspf, where r means relaxed and s strict). If this doesn’t match what you think you published, check your DNS.

    3. row: the headline result for each sender

    Each record represents one sending IP (and one combination of results). The row gives you:

    • source_ip: the server that sent the email
    • count: how many messages it sent in the period
    • policy_evaluated: the DMARC verdict for DKIM and SPF, which means “passed and aligned with your From domain”, plus the disposition (what the provider did: none, quarantine or reject)

    4. auth_results: the raw SPF and DKIM results

    This is the part people misread. auth_results shows whether SPF and DKIM passed for whichever domain they checked. It doesn’t care whether that domain matches yours. That’s why you can see SPF “pass” here but “fail” in policy_evaluated.

    In the example above, SPF passed, but for bounces.platform-example.com, the platform’s own bounce domain. It doesn’t align with yourdomain.co.uk, so DMARC counts SPF as a fail. DKIM, though, was signed by yourdomain.co.uk and passed, so the email passes DMARC overall. That’s a perfectly healthy result.

    The four patterns you’ll see most often

    Both pass: all good

    DKIM and SPF both pass in policy_evaluated. These are typically your main mailbox provider (Microsoft 365 or Google Workspace) and properly configured platforms. Nothing to do.

    DKIM passes, SPF fails: usually fine

    Common for marketing platforms that use their own bounce domain, and for forwarded email (forwarding breaks SPF but not DKIM). DMARC still passes, as in the example above.

    A sender you recognise fails both: fix this before enforcing

    Your CRM, helpdesk, invoicing tool or website form is sending as your domain but isn’t authenticated. Set up DKIM for your domain in that platform, and add it to SPF if it uses your bounce domain. These are exactly the senders that would be blocked if you moved to p=quarantine or p=reject too early.

    An IP you don’t recognise fails both: likely spoofing

    Look up the IP’s owner (any IP “whois” tool will tell you the network). If it’s not a service you use, someone is sending email pretending to be you. That’s the threat DMARC enforcement stops, and a good reason not to sit on p=none for ever.

    A note on the 2026 DMARC update

    In May 2026 the IETF published updated DMARC standards (RFC 9989, 9990 and 9991), replacing the original 2015 specification. The aggregate report format changes slightly. For example, the DKIM selector becomes required and the pct field is dropped. Most providers still send the older format for now, so you may see both. What the reports tell you, and how you act on them, stays the same.

    Why reading XML by hand doesn’t scale

    One report is manageable. But a busy domain receives reports from dozens of providers every day, each listing many IP addresses, and the picture only becomes clear when you combine them over weeks. That’s why most businesses use a DMARC reporting tool that collects the files, groups IPs by sending service and flags new failures automatically.

    Turn your DMARC reports into action

    Our DMARC monitoring service collects your reports, identifies every service sending as your domain, flags spoofing and new failures, and guides you safely to p=reject. Not set up yet? Start by checking your records free.

    See DMARC monitoring
    Check your domain free
  • SPF PermError “Too Many DNS Lookups”: What It Means and How to Fix It

    SPF PermError “Too Many DNS Lookups”: What It Means and How to Fix It

    If an SPF checker or a bounce message has told you SPF PermError: too many DNS lookups, your SPF record has quietly stopped working. Mailbox providers aren’t partly checking it. As far as they’re concerned, it’s broken, and that can drag down DMARC and your inbox placement with it.

    The good news is that it’s one of the most fixable problems in email authentication. Here’s what’s going on and how to sort it.

    What “too many DNS lookups” means

    Your SPF record lists the services allowed to send email as your domain. To check it, the receiving server has to look up each entry in DNS. To stop SPF checks being abused or slowing mail down, the SPF standard (RFC 7208) caps these lookups at 10 per check.

    Go over 10 and the result is a PermError (“permanent error”). The receiver stops evaluating and treats your SPF as failed. That means:

    • SPF can’t help your emails pass DMARC, so you’re relying entirely on DKIM.
    • Any sender that isn’t signing with DKIM for your domain will fail DMARC. Under Microsoft’s rules for Outlook and Hotmail, that can mean 550 5.7.515 rejections.
    • Once you move DMARC to quarantine or reject, those emails go to spam or bounce.

    What counts towards the limit

    Not everything in an SPF record costs a lookup:

    • Each counts as one lookup: include:, a, mx, ptr, exists: and the redirect= modifier.
    • Free (no lookup): ip4:, ip6: and all.

    The catch is nested lookups. When you add include: for a provider, you also take on every lookup inside their SPF record. One include can cost you three or four lookups on its own.

    There’s also a lesser-known second limit: no more than two “void” lookups. These are lookups that return nothing, typically an include: pointing at a service that has since shut down or changed its address. Go over two and you get a PermError too.

    How UK businesses end up over the limit

    It rarely happens all at once. A typical record grows over a few years: Microsoft 365 or Google Workspace, then a newsletter platform, then a CRM, a helpdesk, accounting software that emails invoices, a booking system, the website’s contact form, and a platform someone trialled in 2022 and never removed. Each one asked you to “add our include to your SPF record”, and nobody added up the total.

    v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:mail.crm-example.com include:sendgrid.net include:helpdesk-example.com a mx ~all

    A record like this can easily need 12 to 15 lookups once the nested includes are counted.

    How to fix it

    1. Count your lookups

    Run your domain through an SPF lookup counter that expands every nested include, so you can see which entries cost the most. Write the list down: you’ll need it for the next steps.

    2. Remove anything you no longer use

    This is the quickest win. Ask “do we still use this?” of every include. Old marketing platforms, a previous email host after a migration, and abandoned trials are all common.

    3. Check whether each platform actually needs to be in your SPF

    SPF checks the Return-Path (bounce) domain, not the From address people see. Many marketing and transactional platforms use their own bounce domain unless you set up a custom one. In that case your include: does nothing for SPF at all. Those emails pass DMARC through DKIM signed with your domain instead. Check each platform’s domain authentication settings before removing anything, but this often frees up several lookups.

    4. Swap a and mx for fixed IP addresses

    If your web server or mail server has a fixed IP address, list it with ip4: (free) instead of a or mx (one lookup each). Only do this for IPs you control and that won’t change without you knowing.

    5. Remove ptr

    The SPF standard says ptr should not be used. It’s slow, unreliable and costs a lookup. If it’s in your record, it can almost always go.

    6. Move some senders to a subdomain

    Send marketing from news.yourdomain.co.uk or invoices from billing.yourdomain.co.uk, each with its own SPF record. Every subdomain gets its own 10-lookup allowance, and it keeps the reputation of your marketing mail separate from your day-to-day business email.

    7. Be careful with “SPF flattening”

    Flattening replaces includes with the IP addresses behind them, which brings the count right down. The risk is that providers change their IPs without telling you, and a flattened record silently goes out of date. If you flatten, use a service that keeps the record updated automatically rather than doing it by hand once.

    After you’ve made the change

    • Make sure you still have exactly one SPF record. Two v=spf1 records is a separate PermError.
    • Re-count the lookups: you want 10 or fewer, ideally with a couple spare for the next tool you adopt.
    • Send test emails from each platform and check the headers show spf=pass or an aligned dkim=pass.
    • Watch your DMARC reports for a week or two to catch any sender you missed.

    Check your SPF record now

    Not sure whether your SPF record is healthy? Our free checker looks at your SPF, DMARC and BIMI records in seconds. If you’d rather hand it over, we’ll untangle your SPF record, set up DKIM for every platform you send from and make sure nothing breaks along the way.

    Check your domain free
    Talk to an expert
  • DMARC p=none: What It Means and How to Move to Enforcement Safely

    DMARC p=none: What It Means and How to Move to Enforcement Safely

    If your DMARC record looks like this, your domain is in “monitoring mode”:

    v=DMARC1; p=none; rua=mailto:[email protected]

    That’s a perfectly good place to start. It’s also where a huge number of businesses stop, often for years, without realising what it leaves open.

    What p=none actually does

    DMARC has three policies. Each tells receiving mailbox providers what to do with email that claims to be from your domain but fails authentication:

    PolicyWhat happens to failing emailProtects against spoofing?
    p=noneDelivered as normal; you just get reportsNo
    p=quarantineSent to spam/junkMostly
    p=rejectRefused outrightYes

    So with p=none, someone can send a fake invoice “from” your domain to your customers and it will still be delivered. What you get in return is visibility: the reports sent to your rua address show every server sending as your domain and whether it passes SPF and DKIM.

    Is p=none enough?

    For delivery, mostly yes. Google, Yahoo and Microsoft all require bulk senders to have a DMARC record, and p=none meets that minimum. If you were seeing errors like Microsoft’s 550 5.7.515, a p=none record (plus passing, aligned SPF or DKIM) is what clears them.

    For protection, no. Your domain can still be used in phishing and invoice fraud, which damages your reputation with customers and with mailbox providers.

    For BIMI, no. If you want your logo to appear next to your emails in Gmail and other inboxes, BIMI requires an enforcement policy: p=quarantine or p=reject.

    Why businesses get stuck on p=none

    The fear is reasonable: “If I switch to reject and I’ve missed something, my own emails will stop arriving.” That’s exactly what happens when a business moves too fast. A payroll system, a website contact form, a CRM or an old marketing platform is still sending as the domain without being authenticated, and those emails disappear.

    The way out is not to stay on p=none for ever. It’s to use the reports to find every sender first.

    A safe path from p=none to p=reject

    1. Make sure reports are arriving, and actually read them

    DMARC aggregate reports arrive as zipped XML files, usually daily from each provider. They’re not meant to be read by humans in their raw form. Use a DMARC reporting service (or ours) to turn them into a readable list of sending sources.

    2. List every legitimate sender

    Go through each source in the reports and label it: Microsoft 365 or Google Workspace, your email marketing platform, CRM, helpdesk, accounting software, website, and so on. Anything you don’t recognise is either a forgotten tool or someone spoofing you.

    3. Fix authentication and alignment for each one

    For every legitimate sender, set up DKIM signed with your domain, and add it to SPF where the platform supports it. DMARC passes when SPF or DKIM passes and matches the domain in your From address. DKIM is the more reliable of the two, because it survives forwarding.

    4. Move to p=quarantine

    Once your reports show your legitimate mail passing consistently (we suggest at least two to four weeks of clean data), update the record:

    v=DMARC1; p=quarantine; rua=mailto:[email protected]

    Keep watching the reports. If a legitimate source starts failing, it goes to spam rather than vanishing, so you can catch it and fix it.

    5. Move to p=reject

    After another few weeks with no surprises, go to full protection:

    v=DMARC1; p=reject; rua=mailto:[email protected]

    6. Don’t forget subdomains and parked domains

    Your subdomains inherit your policy unless you set sp=. Domains you own but never send from (old brand names, .ie or .com variants of your .co.uk) should be locked down with v=spf1 -all and p=reject straight away, because they’re easy targets for spoofing.

    How long should the whole process take?

    For most small and medium-sized businesses, six to twelve weeks from p=none to p=reject is realistic. The time goes mainly on tracking down the senders nobody remembered.

    Where does your domain stand?

    Check your DMARC, SPF and BIMI records free: you’ll see your current policy and anything that needs fixing before you move to enforcement. Want it done for you? Our DMARC service handles the reports, finds every sender and takes your domain to p=reject safely.

    Check your domain free
    Talk to an expert
  • How to fix “550 5.7.515 Access denied” from Outlook and Hotmail

    How to fix “550 5.7.515 Access denied” from Outlook and Hotmail

    If you’ve started seeing bounces like this when emailing Outlook, Hotmail or Live addresses, you’re not alone:

    550 5.7.515 Access denied, sending domain [yourdomain.co.uk] doesn't meet the required authentication level.

    It means Microsoft has rejected your email outright. It hasn’t gone to junk; it hasn’t been delivered at all. The good news is that the fix is almost always a DNS change you can make in under an hour.

    Why Microsoft is rejecting your email

    Since 5 May 2025, Microsoft has enforced authentication rules for anyone sending more than 5,000 emails a day to its consumer mailboxes (outlook.com, hotmail.com and live.com, including hotmail.co.uk and live.co.uk). Microsoft originally said non-compliant mail would go to junk. Instead, it chose to reject it, and the 5.7.515 error is the result.

    To get through, your sending domain needs all three of these:

    • SPF must pass: the server sending your email must be listed in your domain’s SPF record.
    • DKIM must pass: your email must carry a valid DKIM signature for your domain.
    • DMARC must exist: at least p=none, and it must align with SPF or DKIM (ideally both).

    The 5,000-a-day threshold is Microsoft’s target, but Microsoft’s own support forums are full of small businesses and individuals hitting this error too. Treat these rules as the minimum for anyone emailing Microsoft customers.

    Step 1: Check what’s actually missing

    Before you touch DNS, find out which of the three checks is failing. You can do this two ways:

    1. Run our free checker. Enter your business email at InboxWizards Free Tools and we’ll check your SPF, DMARC and BIMI records in seconds.
    2. Read the headers of a sent email. Send a message to a Gmail or Outlook address you own, open the original message/headers, and look for the Authentication-Results line. You want spf=pass, dkim=pass and dmarc=pass.

    Step 2: Fix SPF

    Your domain should have one TXT record starting v=spf1, listing every service that sends email as you: your mailbox provider (Microsoft 365 or Google Workspace), your email marketing platform, your CRM, your helpdesk, your invoicing tool and so on.

    v=spf1 include:spf.protection.outlook.com include:_spf.your-email-platform.com ~all

    (Replace the second include: with the value your email platform gives you. Each provider publishes its own.)

    Common mistakes we see:

    • Two SPF records. If you have more than one v=spf1 record, SPF fails for everything. Merge them into one.
    • Too many lookups. SPF allows a maximum of 10 DNS lookups. Pile up enough include: entries and SPF breaks with a PermError.
    • A forgotten sender. A newer tool (a CRM or booking system, say) sending as your domain but not listed in SPF.

    Step 3: Fix DKIM

    DKIM is set up inside each sending platform, not just in DNS. In Microsoft 365, Google Workspace, Mailchimp, Klaviyo, HubSpot and most others, there’s a “domain authentication” or “DKIM” setting that gives you records (usually CNAMEs) to add to your DNS. Add them, then go back and click verify or enable. That last click is the step most people miss.

    The important detail: DKIM must be signed with your domain. If your platform signs with its own domain (for example d=sendingplatform.com), DKIM technically passes but won’t align with DMARC.

    Step 4: Add a DMARC record

    If you have no DMARC record, add a TXT record at _dmarc.yourdomain.co.uk:

    v=DMARC1; p=none; rua=mailto:[email protected]

    p=none is enough to satisfy Microsoft (and Google and Yahoo). The rua address receives daily reports showing every service sending as your domain and whether it passes, which is the information you need to move to a stronger policy later. (Our guide to why DMARC matters covers this in more depth.)

    Step 5: Retest and resend

    DNS changes can take anything from a few minutes to a few hours to take effect. Once they have, send another test email to an Outlook or Hotmail address and check the headers again. When SPF or DKIM passes and aligns with your From domain, and DMARC passes, the 5.7.515 bounces stop.

    Still bouncing?

    If everything passes and you’re still being rejected, the cause is usually one of these:

    • A third-party platform sending as your domain that you didn’t know about (DMARC reports reveal these).
    • Alignment: SPF passes for the platform’s bounce domain but not yours, and DKIM is signed with the platform’s domain.
    • Forwarding, which can break SPF. DKIM is what survives forwarding, so make sure it’s in place.

    Get it sorted today

    Every day these bounces continue, invoices, quotes and campaigns aren’t reaching a big share of your UK customers, as Outlook and Hotmail addresses are everywhere. Our free checker shows exactly what’s missing in seconds. Prefer someone to just fix it? We set up and verify SPF, DKIM and DMARC for UK and Irish businesses, usually without any downtime to your email.

    Check your domain free
    Talk to an expert

  • What is BIMI and How It Works: An Introduction for Email Marketers

    As an email marketer, your primary objective is to get your message across to your target audience. However, despite creating compelling email campaigns, if your emails end up in the spam folder, all your efforts would have been in vain.

    That’s where email deliverability comes in. Email deliverability refers to the ability of your emails to land in your subscribers’ inboxes. Previously we have discussed the more established methods of authentication, but one of the latest technologies that can enhance email deliverability is BIMI (Brand Indicators for Message Identification). In this article, we’ll explore what it is and how it works.

    What is BIMI?

    BIMI is an email authentication protocol that leverages brand logos to authenticate the sender’s identity, which builds upon the DMARC (Domain-based Message Authentication, Reporting, and Conformance) standard, which enables email clients to authenticate the sender’s domain name.

    It allows email marketers to display their brand logo alongside email messages in the recipient’s inbox, subject to the email passing DMARC authentication, adding an additional level of protection.

    Bimigroup.org have a great set of resources including an implementation guide along with supporting documents that they keep up to date.

    How does it work?

    First you must establish DMARC authentication for your domain name, with the policy set at least to ‘quarantine’.

    And remember! DMARC requires that SPF or DKIM has been implemented correctly as a standard so that’s two layers of protection that are required in order to proceed.

    After setting up DMARC, you can generate a BIMI record that specifies the location of your brand’s logo. This record is then publicly available in your domain’s DNS (Domain Name System).

    The recipient’s email client verifies the sender’s DMARC record whenever an email is transmitted. If the email passes, the email client then searches for a BIMI record in the sender’s DNS, and if found, the email client exhibits the sender’s logo and the email message.

    Why use BIMI?

    First and foremost, it enhances email deliverability by improving the sender’s reputation and trustworthiness, aided by the fact that it requires SPF or DKIM and DMARC to succeed.

    Also, you increase brand recognition and recall by displaying your brand logo in the recipient’s inbox, and this can in turn help improve your email open and click-through rates.

    The resulting improvement in engagement can also lead to better deliverability providing other best practices are also maintained.

    Lastly it can also help prevent email phishing attacks as it provides an extra method for verifying the sender’s identity.

    BIMI and the SPF Vulnerability

    What sounds like a bad children’s book is actually a serious case for making sure that you have authentication implemented correctly.

    In June, 2023, a security architect named Chris Plummer was able to send an email that appeared to come from UPS, managing to trick gmail to include the UPS logo and blue check.

    The official statement clarifies that the issue stems from a vulnerability that can occur if SPF is not implemented or if it has been implemented incorrectly. Gmail made some changes as a result and now DKIM is a necessary requirement as a part of your DMARC alignment, where previously SPF was also acceptable.

    Conclusion

    BIMI is a cutting-edge technology that can significantly enhance email deliverability. You can boost brand recognition and recall by showcasing your brand logo in the recipient’s inbox, heighten email open rates and click-through rates, and thwart email phishing attacks. As an email marketer, it’s prudent to implement it to stay at the forefront and enhance the efficacy of your email campaigns.

    Nobody wants to be scammed. We all want to improve subscriber engagement and deliverability that is the best it can be. Get in touch with InboxWizards today, and we can help you set up authentication correctly, troubleshoot any existing problems you might have and monitor your deliverability, ensuring that any future issues are dealt with quickly and effectively.

  • The Power of DMARC: How It Can Keep Your Business Safe

    Ensuring successful email delivery is critical for any email marketing campaign. However, many marketers may face challenges when comprehending the technical components of email deliverability. DMARC, which stands for “Domain-based Message Authentication, Reporting, and Conformance,” is one aspect that marketers need to be familiar with. In this piece we delve into what it is, its significance and impact on email deliverability.

    What is DMARC?

    DMARC is an email authentication protocol that is used to prevent fraudulent emails from being delivered to the recipient’s inbox that builds upon SPF & DKIM, requiring that at least one of them is implemented as a prerequisite.

    SPF allows email senders to specify which IP addresses are authorised to send emails on behalf of their domain.

    Additionally, DKIM, the email authentication method that uses a digital signatures to authenticate emails. The signature lets the receiver know that a message was sent and authorised by the owner of a domain, offering yet another level of security.

    If you need more information regarding how DKIM works, our article can help you get started.

    DMARC is the next layer of protection by adding further parameters that ESPs can check in order to confirm that the email is authentic. In order for an email to be considered authentic it requires that SPF alignment passes as a minimum and can be set up to check for DKIM alignment as well.

    It should be pointed out that Google recently made changes to their requirements choosing DKIM as a prerequisite after an issue arose with SPF, which we cover in our article under the risks of an incorrect setup.

    For a full list of resources linked to the implementation of DMARC visit the official DMARC.org website.

    Why does DMARC matter?

    It is crucial in ensuring email deliverability and protecting your brand’s reputation and it’s worth mentioning that German ESPs have recently placed greater importance on having it implemented.

    First of all, it enables email service providers (ESPs) to determine which emails are legitimate and which are not. This allows ESPs to make better decisions about which emails to deliver to the inbox and which to send to the spam folder, and what emails to block and reject completely.

    As a result, one of the primary benefits is its ability to prevent spoofing and phishing attacks, whereby hackers or cybercriminals send an email using your brand’s domain in order to, essentially, trick people into handing over their money.

    It goes without saying that would be detrimental to your business’s reputation.

    Also, as your customers’ personal information is protected against such attacks, it is important for compliance with regulations such as GDPR, which requires that you take steps to protect their data.

    Although when operating in the EU, RUF reports are not GDPR compliant as they can contain PII (Personally Identifiable Information.)

    To set it up for your domain, you must create a record in your DNS settings.

    What does a DMARC record look like?

    Like SPF, it requires a TXT record be added to a domain’s DNS (Domain Name System) settings. It contains various tags that define the policy and reporting options for the domain. A typical record looks like this:_dmarc.example.com. 3600 IN TXT “v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1”

    Here’s a breakdown of the components in the example DMARC record:

    1. _dmarc.example.com.: This is the record’s location in the DNS, which is created as a subdomain under the primary domain (in this case, example.com).
    2. 3600: This is the Time to Live (TTL) value in seconds, which determines how long the record should be cached by DNS resolvers.
    3. IN TXT: This indicates that the record is an Internet (IN) class TXT (text) record.
    4. “v=DMARC1;: The v tag specifies the version.
    5. p=none;: The p tag defines the policy for handling emails that fail DMARC checks. In this case, none means no specific action should be taken. Other options are quarantine (to mark the message as spam or suspicious) and reject (to reject the message entirely).
    6. rua=mailto:[email protected];: The rua tag specifies the email address to which aggregate reports (RUA reports) should be sent.
    7. ruf=mailto:[email protected];: The ruf tag specifies the email address to which forensic reports (RUF reports) should be sent.
    8. fo=1: The fo tag defines the conditions for generating forensic reports. In this case, 1 means to generate a report if either SPF or DKIM fails.

    There are additional, optional tags that can be included in a record, such as adkim, aspf, pct, and sp, to further customise the policy and reporting options. The tags should be separated by semicolons and enclosed in the double quotes within the TXT record.

    Report Types

    There are two types of reports, known as RUF (Report Using Forensic) and RUA (Report Using Aggregate), they contain data about email authentication results, including information about emails that failed SPF, DKIM, and DMARC checks. These reports help domain owners monitor their email traffic and detect potential issues or malicious activities.

    Conclusion

    DMARC is an essential aspect of email deliverability that helps to prevent spoofing and phishing attacks, improve email deliverability, and ensure compliance with regulations. It helps you protect your brand’s reputation and improve the effectiveness of your email marketing campaigns.

    We offer a full range of deliverability services, including DMARC monitoring packages to ensure that your domain is fully protected and optimised, contact InboxWizards to discuss your requirements with an expert.

  • Why SPF Matters: Protect Your Business Against Email Spoofing Attacks

    Sender Policy Framework (SPF) is an email authentication mechanism that protects businesses against spoofing attacks and unauthorised senders. As a business owner, it’s essential to know how it works and understand the benefits of implementing it.

    How Does SPF Work?

    SPF enables the receiving email server to check that an email claiming to come from a specific domain comes from an IP address authorised by that domain’s administrator. An SPF record is published in the DNS as a TXT resource type, specifying allowed-sender hosts for the selected fields.

    When an email arrives at its destination, the receiving server looks up the corresponding record and checks if the source IP address of that message matches any of those listed in the SPF record. If not, this is suspicious, as the domain’s administrator did not authorise this source.

    What are the Benefits?

    There are many benefits to your email marketing. Firstly, it prevents spoofing attacks that can be used to steal data or commit fraud, which could be disastrous for your business’s reputation and success.

    Secondly, it ensures only legitimate senders can use your domain name when sending emails on behalf of your company.

    Thirdly, it helps ensure all emails contain accurate information about their origin so that spam filters do not block legitimate emails from your company’s address.

    This means more customers are likely to receive important messages related to sales or customer service inquiries instead of getting blocked or marked as spam.

    Ultimately, you are protecting yourself and your customers by verifying and authenticating where emails are coming from and ensuring that only authorised users can send emails on behalf of your business. This process increases customer trust, improves security, and appears in full headers to show you have taken precautions to protect data.

    Risks of an incorrect setup

    Recently a security architect named Chris Plummer was able to take advantage of an SPF vulnerability that occurs when it is not implemented or is done so incorrectly.

    Using the vulnerability he was able to bypass Google’s authentication checks with spoof email claiming to be sent from UPS, even managing to get it to display the logo and blue check.

    BIMI did release a statement that explained the check works as expected and the problem is purely the result of a vulnerability that predates the existence of BIMI and DMARC.

    How To Create An SPF Record

    In order to create an SPF record you need to specify the version of SPF that you are using, the list of IP addresses that have permission to send email on behalf of the domain, any third party domains that also have permission and lastly, add the ‘all’ tag defining the policy applied if an unauthorised server sends on your behalf.

    An example, with a ‘fail’ policy will look a little bit like:
    v=spf1 ip4:xxx.xxx.xxx.xxx include: domain.com -all

    Once prepared it is possible to use a record checker tool that will compare it with a set of criteria confirming whether it has been set up correctly.

    SPF Checker Criteria

    To ensure a secure and protected email system, a record checker tool provides stringent security in identifying spoofed emails. These checks involve the criteria of making sure there are fallback mechanisms and that the SPF macro is valid.

    Another important factor the checker tool will test for is the number of DNS lookups, it’s important that it does not exceed the maximum of ten; if so, you may need to re-evaluate and simplify the configuration.

    Once you have gone through this process and passed the criteria set forth by the checker tool, you can add the record to your DNS as a TXT resource type.

    With all criteria met you can have confidence in your email reputation, knowing that only authorised senders will be able to deliver mail on behalf of your domain.

    Overall, this distinction between authenticated and non-authenticated emails provides an extra layer of trust for online users relying on messages and communication via emails.

    Conclusion

    Implementing a Sender Policy Framework correctly is essential for protecting your business, stakeholders and customers.

    While creating the TXT records and using the checker tools to verify a correct setup are relatively straightforward, troubleshooting isn’t always so easy.

    If you want to avoid all the trouble of setting up an SPF record, having a professional inbox-focused company supporting your email marketing campaigns helps you make the process easier and more efficient.

    This way, you’ll be able to ensure your business is adequately protected against malicious threats and provide a secure online environment for customers to communicate with you effectively – without having to lift a finger!

    At InboxWizards, we offer clients a comprehensive suite of email services to help keep their businesses safe and secure. Contact us today for more information!