Sender rules last reviewed on 5 October 2026. Mailbox providers change their requirements often. This is general information, not legal advice, so confirm specifics with each provider's current guidance and your own counsel.
Most finance and operations teams do not have an email problem. They have a "did it arrive?" problem: an invoice went out on Friday, the customer never saw it, and nobody can show what happened in between.
This guide covers email automation for business events: how to design each message, how sender authentication and mailbox-provider rules affect it, where transactional and marketing email blur, and how to keep proof. It sits alongside the B2B accounting workflows guide.
The event, recipient, message, proof loop
Every automated email worth sending follows four steps, and if one is missing the email becomes noise or disappears.
- Event. Something happens in a system of record: an invoice is finalised, a payment is matched, an approval is escalated.
- Recipient. A rule decides who needs to know: the customer's billing contact, the manager above the one who did not respond, the person who raised the purchase order. Not a shared mailbox by default.
- Message. The email goes out from an authenticated domain, saying what happened and what to do next.
- Proof. A delivery result or bounce is logged against the record, so anyone can see what was sent, to whom and when.
Teams usually automate step 3 and forget step 4, then learn about failures from an angry phone call.
An event catalogue for finance and operations
Start with events that already trigger manual follow-up. This is a starting point, not a standard.
| Event | Recipient | Subject pattern | The message must contain |
|---|---|---|---|
| Invoice issued | Customer billing contact | Invoice INV-1042 from [Company], Rs 1,18,000 due 20 Nov | Number, date, amount, due date, the invoice or a secure link, payment details, a contact for queries |
| Payment received | Billing contact | Payment received for INV-1042 | Amount, date, invoice settled, balance left |
| Payment reminder | Billing contact | Reminder: INV-1042 due on 20 Nov | Number, amount outstanding, due date, how to pay, who to tell if already paid |
| Approval escalated | Manager above the approver who did not respond | Approval pending 3 days: PO-221 | What needs approval, who was asked, how long it has waited, a link to decide |
| Approval decided | Person who raised the request | PO-221 approved by [Name] | Decision, who and when, any comment, next step |
Put the identifying reference in the subject so the email can be searched, keep the amount and date in the body rather than only in an attachment, and name a real person the recipient can reply to. For invoice content such as GSTIN and IRN, see the GST e-invoicing guide, and send only after the invoice is final.
Choosing the recipient
Store the invoice recipient on the customer record, separately from the sales contact, and review it when an email bounces. For approvals, define escalation in advance: who is asked first, how long before the next person is told, and what happens if they are on leave. The same discipline runs through procure-to-pay for Indian MSMEs.
Sender authentication and the rules mailbox providers publish
Mailbox providers decide what reaches an inbox, and since early 2024 Google and Yahoo have published explicit sender requirements. These are their stated rules, not delivery guarantees.
Three acronyms do most of the work. SPF lists which servers may send for your domain. DKIM adds a signature proving the domain authorised the message and it was not altered. DMARC tells receivers what to do when those checks do not line up with the visible From domain, and sends you reports.
Sender requirements at a glance
| Requirement | All senders | Bulk senders |
|---|---|---|
| SPF or DKIM | At least one (Google, Yahoo) | Both SPF and DKIM |
| DMARC | Not required | Valid policy; p=none is the minimum |
| From domain alignment | Good practice | Google: must align with the SPF or DKIM domain |
| Forward and reverse DNS | Valid records | Same |
| TLS | Google: required | Same |
| Spam rate | Below 0.3% (Google Postmaster Tools; Yahoo cites the same figure) | Same |
| One-click unsubscribe | Not required for transactional mail | Required for marketing and subscribed mail (List-Unsubscribe and List-Unsubscribe-Post headers); Yahoo also wants a visible link and unsubscribes honoured within 2 days |
- Google defines a bulk sender as one sending close to 5,000 or more messages to personal Gmail accounts in 24 hours, and says bulk status does not expire. A small business can cross that on a busy month-end, so authenticate everything as if you were bulk.
- Google asks for DKIM keys of at least 1024 bits and recommends 2048.
- Microsoft has reportedly announced requirements for domains sending more than 5,000 emails a day to Outlook.com, Hotmail.com and Live.com, effective 5 May 2025: SPF and DKIM must pass, DMARC must be at least p=none and aligned, and non-compliant mail may go to Junk or be rejected. This is reported; confirm in Microsoft's announcement.
Transactional email vs marketing email: the line is not clean
The core idea: transactional email is triggered by something the recipient did or that affects their own account; marketing promotes. Google says one-click unsubscribe is required only for marketing and promotional messages, and that transactional messages are excluded. Its examples are password resets, reservation confirmations and form submission confirmations.
Two cautions follow. First, invoices and payment reminders are not among Google's examples, so do not assume they are exempt. Google also says the distinction can vary by industry and applicable regulations, and that recipients, not Google, determine the nature of the messages they receive.
Second, mixing the two weakens both. Keep invoice, receipt and reminder emails strictly about the recipient's own account and the amount owed. Leave out offers and cross-sell, even a small banner. Treat anything promotional as marketing, with its own send and a working unsubscribe, and where practical use a different subdomain for it.
Consent and the coming data protection rules
India's Digital Personal Data Protection Rules were notified on 13 November 2025. The main consent and notice obligations are reported to take effect around mid-May 2027, so they are not in force today.
Build to that standard now: record why you hold each address, keep working opt-out handling, and do not repurpose billing contacts for promotion. For how OpsGrids handles contact data, see the platform privacy section.
Content and cadence for payment reminder emails
Payment reminder emails work best when predictable, specific and polite. A common pattern is a courtesy note a few days before the due date, a plain "now due" message on or just after it, a firmer one with a named contact after a set number of overdue days, and then a phone call from the account owner rather than a fourth automated message.
Set the intervals from your payment terms and write them down so every customer gets the same schedule.
Content rules that help:
- State the invoice number, amount outstanding and due date in the first lines.
- Say what to do if it has already been paid, and who to tell.
- Stop the sequence the moment a payment is matched.
Pre-launch checklist
Before turning on any automated event email:
- SPF and DKIM are set, a DMARC record exists (at least p=none), and the From domain aligns.
- Forward and reverse DNS are valid, TLS is used, and DKIM keys are 2048-bit where supported.
- Someone watches the spam rate (for example in Google Postmaster Tools).
- Marketing and event email are separated, and promotional mail has one-click unsubscribe.
- Every event has a defined recipient, subject pattern and required content.
- Bounces are logged against the record and someone owns the follow-up.
- Reminders stop automatically on payment.
- Each event has been tested to Gmail, Outlook and Yahoo inboxes.
Common mistakes
- Sending from a mismatched domain. The From address says one domain and the signature another.
- Stopping at p=none. It meets the minimum, but reading the DMARC reports shows who else sends as you.
- A shared inbox as recipient. Nobody owns it.
- Promotion inside reminders. It muddies the category and invites complaints.
- Ignoring bounces. One typo can mean weeks of silent non-delivery.
- Assuming transactional means exempt. Rules differ by provider and regulation, and recipients judge for themselves.
Which OpsGrids events can reach email today
This article is a guide to doing event email well. OpsGrids today covers the event-notification part of it.
Notification rules route events from the products to people on WhatsApp or email, and a delivery receipt comes back. The rules screen is shown on the home page.
For example, an escalated approval step in HRMS goes by email to the manager above the one who did not answer, and a storefront postal-code import goes by email to the operations team. Email is one of two live channels, alongside WhatsApp (see the WhatsApp automation guide).
OpsGrids does not have an email campaign builder, newsletters or bulk sending, an email inbox, a template editor, SMS, open or click tracking, or sender-domain setup screens. Marketing has no send path. For the full list of products and their gaps, see Products.
FAQ
Do I need SPF, DKIM and DMARC if I send only a few hundred invoices a month? Google and Yahoo require SPF or DKIM from all senders, and DMARC for bulk senders. Setting up all three is still sensible: Google says bulk status does not expire once reached, and DMARC reports reveal misuse of your domain.
Is an invoice email transactional, so I can skip unsubscribe? Do not assume so. Invoices and reminders are not in Google's examples, and recipients decide the nature of a message. Keep them strictly about the recipient's account and treat anything promotional as marketing.
How often should I send payment reminders? There is no standard. A short, fixed sequence around the due date, stopped on payment and followed by a personal contact, is easier to defend than open-ended repetition.
How do I know an email was delivered? Log the delivery result or bounce against the record. Delivered means the receiving server accepted it, not that anyone read it or that it avoided a spam folder.
Next step
If you want event notifications tied to your invoices and approvals, Talk to our team.
Sources (checked 5 October 2026)
- Google, email sender guidelines and FAQ (support.google.com, Gmail help for senders)
- Yahoo, sender best practices (senders.yahooinc.com)
- Microsoft Tech Community, Outlook.com sender requirements announcement (reported; confirm in the announcement)
- Digital Personal Data Protection Rules, 2025: dates are from secondary reports; confirm on meity.gov.in before relying on them
- IETF, RFC 5322, RFC 7208 (SPF), RFC 6376 (DKIM), RFC 7489 (DMARC), RFC 8058 (one-click unsubscribe)