Not receiving sample emails in Outlook | Community
Skip to main content
C
CJF
Level 2
June 17, 2026
Question

Not receiving sample emails in Outlook

  • June 17, 2026
  • 2 replies
  • 27 views

I am trying to send a sample email to my Outlook (work) and I am not receiving them. I have checked SPAM and JUNK folders and they are not in there. It states that the email has been sent via Marketo. Can someone please help troubleshoot?

    2 replies

    A
    adesrala1
    Level 2
    June 18, 2026

    If Marketo says 'Sent' but it's missing from Spam/Junk, your corporate firewall is likely silently dropping it. Test this by sending a sample to a personal Gmail, if it arrives, your asset and personalization are working fine. You can also try a live deployment to your work email address instead of a 'Send Sample,' as firewalls often treat them differently. If it hits Gmail but not Outlook, have your IT team allowlist Marketo's sending IPs!

    Here is how to troubleshoot this step-by-step:

    Step 1: Check the Lead Activity Log

    Before diving into technical fixes, verify exactly what Marketo recorded. Go to your lead record in the database and look at the Activity Log:

    • Do you see a 'Delivered Email' activity? If yes, the receiving server officially accepted it. It is 100% being blocked by your internal IT security layer (like Mimecast, Proofpoint, or Microsoft Defender).

    • Do you see a 'Bounce Email' activity? Double-click it to read the raw error text. It will tell you if there is an instant authentication or IP rejection.

    Step 2: The Core Culprit (Internal IT Allowlisting)

    Corporate networks treat emails that look like they are coming from your company (@yourcompany.com) but originate from an external server (Marketo's IPs) with extreme suspicion.

    The Fix: You need to open an internal IT ticket with your Network/Email Admin team and request that they allowlist Marketo's sending IP addresses for your instance.

    Tip: You can find your specific sending IPs in your instance under Admin > Email > Whitelisting to hand over to your IT team.


    Step 3: Audit Your DNS Authentication

    Modern corporate firewalls will instantly destroy emails if your authentication isn't perfectly configured. Check with your web/IT team to ensure these are set up in your DNS:

    • SPF: Marketo’s domain/IPs must be included in your company's SPF record.

    • DKIM: Ensure your sending domain shows as 'Verified' under Admin > Email in Marketo.

    • DMARC: If your company enforces a strict DMARC policy (p=reject), any unauthenticated test will be permanently deleted.

      SanfordWhiteman
      SanfordWhiteman
      Level 10
      June 18, 2026

       

      Step 2: The Core Culprit (Internal IT Allowlisting)

      Corporate networks treat emails that look like they are coming from your company (@yourcompany.com) but originate from an external server (Marketo's IPs) with extreme suspicion.

       

      Far too broad of a generalization. Any competent mail admin, and all modern mail servers, knows how to deal with a range of IPs emitting (authenticated) email from your domain. Some admins are incompetent and overly punitive, absolutely, but the solution isn’t wholly allowlisting Marketo’s IPs, which just marks them as even less competent!

       

      Unless you have a static IP (a considerable additional cost) you share your Marketo IPs with many other users. Allowlisting IPs means anyone using those other Marketo instances can send to your users without spam inspection,  clearly a bad move.

       

      Allowlisting based on valid DKIM signature from your company’s domain is the proper method, if you must allowlist at all. But even that means you’re getting the false comfort that your emails are getting into your leads’ inboxes, when in reality you may have a fatal misconfig that you’ve just bypassed internally but which still affects everybody else.

       

      • SPF: Marketo’s domain/IPs must be included in your company's SPF record.

      There is no circumstance where you need Marketo’s SPF included in your company’s SPF record (as in the record for example.com).

       

      If you don’t have a branded envelope sender, again a paid add-on, you don’t need to make any SPF updates at all. If you do have a branded envelope, like bounces.example.com, it’s that subdomain that needs its SPF record updated, not the main domain. 

       

        A
        adesrala1
        Level 2
        June 18, 2026

        Fair points! Relying solely on IP allowlisting definitely has its pitfalls, especially on shared infrastructure. The mechanics of Return-Path authentication get overlooked so easily, and you're exactly right about where that SPF record actually needs to live depending on the branded envelope setup.

        C
        CJFAuthor
        Level 2
        June 18, 2026

        Thank you both! I’ll refer the info to IT so they can take a look into it. I’ll keep you posted.

        Terms & ConditionsAccessibility statement

        Loading footer...