A founder in r/Emailmarketing recently raised a familiar concern: users request an audit report from a self-serve tool, the report arrives via Resend from a subdomain, and a few messages have landed in spam. The email contains HTML, tracked links, and a PDF attachment—exactly the sort of useful product-email bundle that can become hard to diagnose when inbox placement slips.

The important distinction is that this is requested, transactional mail, not cold outreach or a promotional newsletter. That is a strong starting point. But “transactional” is not a deliverability exemption. Mailbox providers still evaluate authentication, sending-domain history, recipient behavior, message format, and complaint signals. Google’s sender guidance applies baseline authentication expectations to all senders, while larger Gmail senders face additional requirements and monitoring expectations. Google’s sender guidelines also make clear that sending volume is aggregated at the primary-domain level for Gmail’s bulk-sender classification—so a subdomain is useful segmentation, not a magical wall around the parent domain.

Keep the subdomain, but organize it around intent

The Reddit poster’s current architecture is directionally right. Resend explicitly recommends sending from a purpose-specific subdomain rather than the root domain, both to clarify the mail’s purpose and to isolate reputation by stream. A sender such as reports.example.com or notify.example.com is more credible than an unrelated lookalike domain and easier to separate from a future marketing stream.

The practical setup is:

  • Product reports: reports.example.com
  • Lifecycle or newsletter email: news.example.com or updates.example.com
  • Transactional return path and tracking: dedicated, aligned subdomains configured through the provider

This does not mean the root domain is untouched by reputation. Gmail notes that messages from subdomains can count toward the same primary-domain volume threshold. But separating streams still limits operational risk: a marketing campaign’s complaints or a sudden spike should not share the exact same sending identity and message pattern as a user-requested report.

Treat the attachment as a delivery choice, not a default

A PDF attachment is not inherently spammy, and neither are HTML or custom tracking links. The problem is that every added element gives filters, corporate gateways, and recipients another reason to scrutinize a message. Attachments can be blocked by security controls; link rewriting can make a message look more complicated; and an image-heavy HTML report may leave too little plain-language context for the recipient.

For most self-serve reports, the better default is a short email containing the key result and a prominent button to view or download the report from the product. Make the report link signed, access-controlled where appropriate, and time-limited if the content is sensitive. Offer the PDF as an optional download on the report page rather than attaching it automatically.

That approach has two benefits: it removes an attachment variable from the inbox-placement problem, and it turns the email into a clear continuation of an action the user just took. If the attachment is essential—for example, because users need to forward a formal report—test an attachment-free version against it before assuming the PDF is the cause.

Build for recognition, not just authentication

Authentication remains non-negotiable. Configure SPF and DKIM for the actual sending subdomain, and publish DMARC at the organizational domain with reporting enabled. Google recommends both SPF and DKIM, and its DMARC guidance warns that enabling DMARC before third-party senders are properly authenticated can create delivery failures. Yahoo likewise requires authentication and expects SPF, DKIM, and DMARC from bulk senders.

Then make the message immediately recognizable:

  • Send from a human-readable address such as reports@reports.example.com.
  • Use a subject that matches the on-site action: “Your requested website audit report.”
  • State why the recipient is receiving it in the first line: “You requested this report at [brand] a moment ago.”
  • Include a plain-text part, a real reply path, and a restrained HTML layout.
  • Avoid unnecessary click tracking, especially on the primary report-download link, until you know it is needed.

This is also where product teams can outperform generic email programs. The request happens on a web page; preserve that context in the email. A report that arrives within seconds, uses the same branding, and repeats the requested audit name is less likely to be ignored or marked as spam.

Monitor the right signals before changing infrastructure

One or two spam-folder observations are a reason to investigate, not proof that the domain is damaged. Start by checking authentication alignment and provider event data: bounces, deferrals, complaints, and delivery failures. Google Postmaster Tools can surface Gmail-domain reputation, spam-rate, authentication, and delivery-error data once there is enough eligible volume.

Also watch for volume spikes. Resend’s deliverability guidance advises gradually increasing volume when a domain, vendor, or sending pattern changes. A viral launch that turns a handful of reports into thousands overnight deserves the same ramp-up planning as a newsletter launch.

The takeaway from the Reddit question is simple: don’t solve an occasional spam placement by abandoning the main brand domain or buying a new “sending domain.” Keep a branded, purpose-specific subdomain; authenticate and align it correctly; simplify the report email; and measure real failure signals. Requested reports should be one of the healthiest mail streams a product sends—provided the sending setup makes that request obvious to both recipients and inbox providers.

Original discussion: “Best way to send self-serve audit report emails?” posted by u/JustAchillDev in r/Emailmarketing. The thread had no substantive top-comment consensus at the time reviewed.