The information below is specific to customers configuring emails for MicrOpay in the Hosted Online environment. The configuration for on-premise or desktop customers will be different.
Your MicrOpay environment is hosted on The Access Group’s cloud infrastructure in Microsoft Azure. All outbound emails from MicrOpay — payslips, notifications, reports, and other communications — are sent through our centralised email relay.
Following are the available email configuration options, what is required for each, to help you choose the best approach for your organisation.
Why Email Configuration Matters
Since 2024, major email providers (Google, Microsoft, Yahoo) have enforced strict email authentication. Emails that fail SPF, DKIM, or DMARC checks are silently dropped — your payslip emails may never reach employees, and MicrOpay will not show an error.
Choosing the right email configuration ensures your payroll communications are delivered reliably.
MicrOpay in the Hosted Online environment supports four SMTP-based email configuration approaches, plus Microsoft Graph API integration for clients wanting fully branded email from their own domain. Detailed information about the different approaches is in Configuration options.
MicrOpay sends emails by
When MicrOpay sends an email (e.g., a pay advice):
Step | What Happens |
1. MicrOpay generates the email | The application creates the email using the From address, Reply-To address, and SMTP settings configured in Access MicrOpay Evo Administration, System Configuration, System Wizard. |
2. Email is sent to the relay | MicrOpay connects to our centralised mail relay (or your own SMTP server, if configured) and submits the email. |
3. Relay delivers to the recipient | Our relay forwards the email to the recipient’s email provider (e.g., Gmail, Outlook). |
4. Recipient’s provider checks authentication | The receiving server checks SPF, DKIM, and DMARC records to verify the email is legitimate. |
5. Email is delivered or rejected | If authentication passes, the email reaches the inbox. If it fails, the email is silently dropped or sent to spam. |
📌Note: The recipient’s email provider decides whether to accept or reject the email based on whether the From address domain matches the sending infrastructure’s authentication records.
Network and port restrictions
The hosted environment has network restrictions that affect which email configurations are possible. The following ports are available:
Port | Protocol | Availability in Hosted environment | Used by |
25 | SMTP (unencrypted) | Internal only — available for communication with our centralised relay within the hosted network. Blocked for all external destinations. | Options A, B, C |
465 | SMTPS (implicit TLS) | Blocked. This is a deprecated legacy port and is not available in the hosted environment. | Not available |
587 | SMTP Submission (STARTTLS) | Restricted — outbound connections on port 587 are only permitted to Microsoft 365 SMTP endpoints (smtp.office365.com). Connections to non-Microsoft SMTP servers (e.g., Gmail, Yahoo, or your own mail server) are blocked. | Option D (Microsoft 365 only) |
443 | HTTPS | Open — confirmed accessible to both graph.microsoft.com and login.microsoftonline.com. | Graph API |
⚠️ Important: Option D is limited to Microsoft 365 SMTP only.
Port 587 is the only port available for external SMTP connections, and it is restricted to Microsoft 365 endpoints. If your organisation uses a non-Microsoft SMTP server (e.g., your own on-premise mail server, Gmail, or another third-party provider), MicrOpay will not be able to connect to it from the hosted environment.
If you require emails to be sent from your own domain, Microsoft Graph API is the recommended approach — port 443 is fully available and is not subject to the same restrictions as SMTP ports.
Email authentication
Three protocols work together to verify that an email is genuinely from who it claims to be:
Protocol | What it does | In plain english |
SPF | Lists which servers are authorised to send email for a domain. | Is this server allowed to send email as @example.com? |
DKIM | Adds a cryptographic signature that proves the email wasn’t tampered with. | Can we verify this email is authentic and unmodified? |
DMARC | Tells receiving servers what to do when SPF or DKIM fails. | If the checks fail, should the recipient reject, quarantine, or allow the email? |
⚠️ Important: Custom From addresses fail.
When MicrOpay sends an email with From: [email protected], the recipient’s email provider checks your domain’s SPF and DKIM records against our sending infrastructure. Unless you have explicitly configured your DNS to authorise our relay (Option C), these checks will fail. The recipient’s provider treats this as a spoofed email and silently discards it.
This is the same mechanism that protects you from phishing emails — it’s working as designed.
Configuration options
MicrOpay supports four SMTP-based email configuration approaches, plus Microsoft Graph API integration for clients wanting fully branded email from their own domain. We recommend Option A or B for most clients, and Graph API for clients who need emails to come from their own domain.
📌Note: If you are experiencing email delivery problems with a non-standard configuration (Options C, D, or any custom settings), our support team will always recommend switching to the standard configuration (Option A) as the first troubleshooting step. The standard configuration is fully managed and authenticated by us, eliminating the most common causes of delivery failure.
Once email delivery is confirmed as working with the standard configuration, we can then work with you to re-establish your preferred setup or explore Graph API as an alternative.
Option A — Standard configuration (recommended)
Use our default From address with our centralised relay. This is the simplest and most reliable.
MicrOpay settings | Value |
From Address (SMTPFrom) | |
Reply-To Address (SMTPReplyTo) | Your preferred address (e.g., [email protected]) |
SMTP Server (SMTPServer) | Default (our centralised relay) |
SMTP Port (SMTPPort) | 25 (internal relay only — see Network and port restrictions) |
SMTP Authentication | Disabled |
This works because the From address uses a domain we control (cloud.micropay.com.au). We manage the SPF, DKIM, and DMARC records for this domain, ensuring all authentication checks pass at the recipient’s provider.
When recipients click Reply, their response goes to your Reply-To address — giving you the practical benefit of branded replies without breaking email authentication.
Setup required
None, as this is the default configuration. Contact support if your database is not already configured this way.
Option B — Client-identified from address
Use a per-client From address on a domain we control, giving you a unique sender identity while maintaining full authentication.
MicrOpay settings | Value |
From Address (SMTPFrom) | [YourClientId]@cloud.micropay.com.au |
Reply-To Address (SMTPReplyTo) | Your preferred address (e.g., [email protected]) |
SMTP Server (SMTPServer) | Default (our centralised relay) |
SMTP Port (SMTPPort) | 25 (internal relay only — see Network and port restrictions) |
SMTP Authentication | Disabled |
This gives your organisation a unique, identifiable From address (e.g., [email protected]) while still using a domain we fully authenticate. Useful for traceability, and if you want mail flow rules to filter by sender.
Setup Required
Contact support to request a client identifier to be configured. No DNS changes are required on your end.
Option C — Custom From address (your domain)
Use your own domain as the From address (e.g., [email protected]). This requires DNS changes on your domain to authorise our relay to send on your behalf.
🤓 Tip: Consider Graph API instead.
Option C requires DNS changes on your domain and ongoing maintenance of those records. If your goal is to send email from your own domain, we recommend Microsoft Graph API integration (see Microsoft Graph API) as the better path. Graph API sends email directly through your own Microsoft 365 tenant with full authentication alignment — no DNS changes to maintain, no relay dependencies, and complete delivery visibility through your own Microsoft 365 admin centre.
If you do not have Microsoft 365 or prefer to use our relay, Option C is available with the DNS configuration below.
If you proceed with this option, the following DNS changes are required on your domain:
DNS record | What to add | Purpose |
SPF (TXT record) | Add our sending IP range to your existing SPF record using an include: or ip4: mechanism. | Authorises our relay to send emails as your domain. |
DMARC (TXT record) | Review your DMARC policy to ensure it aligns with your SPF configuration. We can advise on appropriate settings during setup. | Controls how receiving servers handle emails that fail authentication checks. |
Setup required
You (or your IT team / DNS provider) must update your domain’s DNS records. Contact support to obtain the specific IP addresses or include mechanism to add. You are responsible for maintaining these records if our infrastructure changes.
Your ongoing responsibilities
Maintain your SPF record, monitor your domain’s DMARC reports, and update records if notified of infrastructure changes.
Option D — Your own SMTP server (Microsoft 365 only)
Configure MicrOpay to send email through your own Microsoft 365 SMTP endpoint rather than our centralised relay.
⚠️ Important: This is not recommended as significant restrictions apply.
Due to network restrictions in the hosted environment, outbound SMTP connections on port 587 are only permitted to Microsoft 365 endpoints (smtp.office365.com). Connections to non-Microsoft SMTP servers are blocked. This means Option D is only available to clients with a Microsoft 365 subscription.
Microsoft Graph API is a significantly better option for Microsoft 365 — it provides the same branded email capability with none of the credential, firewall, or monitoring limitations of SMTP.
If you do not have Microsoft 365, Options A or B are the only viable configurations.
If you choose to proceed with Option D, the following requirements apply:
Microsoft 365 subscription with Exchange Online
SMTP AUTH must be enabled on the sending mailbox (disabled by default in Microsoft 365)
Port 587 with STARTTLS to smtp.office365.com (the only external SMTP endpoint reachable from the hosted environment)
Credentials that do not expire and do not require multi-factor authentication (MFA)
Basic authentication or app passwords are configured for the sending account
If you have Microsoft 365, use Graph API instead
Option D requires Microsoft 365 — but so does Graph API. If you already have Microsoft 365, Graph API gives you everything Option D provides plus full delivery visibility, no credential management, no SMTP AUTH dependency, and error reporting back to MicrOpay. There is no scenario where Option D is a better choice than Graph API for Microsoft 365 clients
Delivery Beyond Your SMTP Server
Successfully delivering the email from MicrOpay to smtp.office365.com is only the first step. Your Microsoft 365 tenant must then deliver the email onward to the recipient’s email provider. The recipient’s provider will check authentication (SPF, DKIM, DMARC) against your sending domain — the checks described in email authentication.
If your domain’s authentication records are not correctly configured in Microsoft 365, the recipient’s provider may silently reject the email even though Microsoft 365 accepted it from MicrOpay.
This means Option D has three potential failure points:
MicrOpay connecting to smtp.office365.com.
Microsoft 365 accepting and processing the email.
The recipient’s provider accepting the email based on your domain’s authentication records.
We have no visibility to any of these stages.
What we provide | What we do not provide |
Configure MicrOpay with your Microsoft 365 SMTP settings as requested. | Monitoring of your Microsoft 365 SMTP delivery or mailbox availability. |
Confirm MicrOpay is submitting emails to smtp.office365.com. | Troubleshooting of your Microsoft 365 tenant, mailbox, or SMTP AUTH configuration. |
Advise on MicrOpay-side SMTP settings. | Bounce tracking or delivery reports from your Microsoft 365 tenant. |
Escalation path if MicrOpay itself is not generating emails. | SLA coverage for email delivery failures caused by your Microsoft 365 SMTP configuration. |
| Verification or troubleshooting of your domain’s SPF, DKIM, or DMARC configuration. |
Setup required
Provide your M365 SMTP credentials (email address and app password or SMTP AUTH-enabled password) to support. You must ensure SMTP AUTH is enabled on the sending mailbox in your Microsoft 365 tenant. The SMTP endpoint is smtp.office365.com on port 587.
Your ongoing responsibilities
Maintain your Microsoft 365 mailbox, credentials (including rotation and MFA exclusions), and SMTP AUTH enablement. Ensure your domain’s SPF, DKIM, and DMARC records are correctly configured within your Microsoft 365 tenant. Monitor your own bounce reports and delivery logs through the Microsoft 365 admin centre.
Comparison of Options
| A: Standard | B: Client-ID | C: Your Domain | D: Microsoft 365 SMTP |
From address | [YourID]@cloud.micropay.com.au | Your choice (Microsoft 365 mailbox) | ||
Port | 25 (internal relay) | 25 (internal relay) | 25 (internal relay) | 587 to smtp.office365.com only |
Requires Microsoft 365 | No | No | No | Yes |
SPF | ✅ Pass | ✅ Pass | ✅ Pass (if configured) | Your responsibility |
DKIM | ✅ Pass | ✅ Pass | ✅ Pass (with DNS configuration) | Your responsibility |
DMARC | ✅ Pass | ✅ Pass | ✅ Pass (with DNS configuration) | Your responsibility |
Authentication managed by | The Access Group (both hops) | The Access Group (both hops) | Shared — we handle relay, you handle DNS | Entirely your organisation |
Delivery chain | MicrOpay → our relay → recipient (we manage end-to-end) | MicrOpay → our relay → recipient (we manage end-to-end) | MicrOpay → our relay → recipient (relay managed by us, DNS by you) | MicrOpay → smtp.office365.com → recipient (you manage both hops) |
Deliverability | Best | Best | Good (requires correct DNS setup) | Depends on your Microsoft 365 config and DNS |
Setup effort | None | Minimal (support request) | DNS changes required | Significant (SMTP AUTH, credentials, MFA exclusions) |
Ongoing maintenance | None | None | You maintain DNS records | You maintain credentials, SMTP AUTH, DNS, and delivery monitoring |
SRE monitoring | ✅ Full | ✅ Full | ✅ Relay side only | ❌ None |
SLA coverage | ✅ Yes | ✅ Yes | ⚠️ Partial | ❌ No |
Configuration to avoid
Configuration | Problems caused |
Setting the From address to your own domain without DNS changes (Option C prerequisites). | Our infrastructure is not authorised to send as your domain. All authentication checks fail and emails are silently dropped. |
Using a free email address (Gmail, Hotmail, Yahoo) as the From address. | These providers publish strict DMARC reject policies. Any email sent from a non-Gmail/Hotmail server with their domain in the From address is guaranteed to be rejected. |
Enabling SMTP authentication against our relay. | Our centralised relay does not require authentication. Enabling it in MicrOpay causes 535 authentication errors and all emails will fail to send. |
Using SMTP credentials that expire or require MFA (Option D). | Credential-based failures are invisible to MicrOpay users. Emails stop sending with no notification. |
Configuring an external SMTP server on port 25. | Port 25 is blocked for all external destinations. Only internal relay traffic to mail.hostedmicropay.local is permitted on port 25. |
Using a non-Microsoft SMTP server for Option D. | Port 587 is only open to Microsoft 365 endpoints (smtp.office365.com). Connections to Gmail, Yahoo, or any other SMTP provider are blocked at the network level and will fail silently. |
Using port 80 or other non-SMTP ports for email. | Port 80 is HTTP, not SMTP. MicrOpay will attempt an SMTP handshake against a non-SMTP service and fail silently. Emails will never be sent. |
Using port 465 (legacy SMTPS). | Port 465 is blocked in the hosted environment. Use port 587 with STARTTLS to smtp.office365.com, or use Graph API on port 443. |
Microsoft Graph API - Recommended for branded email
If your organisation wants emails to come from your own domain (e.g., [email protected]) with full authentication and complete delivery visibility, Microsoft Graph API integration is recommended.
Unlike Options C and D, which require DNS changes or your own SMTP server and still leave gaps in visibility or ongoing maintenance, Graph API sends email directly through your own Microsoft 365 tenant. This means your organisation’s existing email infrastructure handles the sending — the same infrastructure that sends your regular business email.
Why Graph API Is the Best Path for Branded Email
Full authentication: Emails are sent from your Microsoft 365 tenant, so SPF, DKIM, and DMARC all align with your domain automatically. No DNS changes, no SPF record maintenance, no relay dependencies.
Complete visibility: Delivery tracking, bounce reports, and message traces are available through your own Microsoft 365 admin centre — the same tools your IT team already uses for business email.
No credentials to manage: Authentication uses Azure AD application tokens with automatic refresh. No passwords that expire, no MFA complications, no shared credentials.
No firewall or network dependencies: Graph API uses HTTPS (port 443), which is confirmed open to both graph.microsoft.com and login.microsoftonline.com from the hosted environment. Unlike SMTP ports, there are no restrictions on which endpoints can be reached.
Your IT team retains full control: The sending identity, mailbox, and application permissions are all managed within your own Azure AD tenant.
No ongoing maintenance: Once configured, it simply works. No DNS records to update if our infrastructure changes, no credentials to rotate.
How It Works
Your IT team registers an application in your organisation’s Azure Active Directory (Entra ID) tenant and provides three values to us to configure in your MicrOpay database:
Tenant ID — identifies your Microsoft 365 tenant.
Client ID — identifies the registered application.
Client Secret — the application credential (rotated on your schedule).
MicrOpay then sends email directly through the Microsoft Graph API using your tenant’s identity. The email originates from your Microsoft 365 environment, so it is indistinguishable from any other email your organisation sends.
Requirements
Microsoft 365 subscription with Exchange Online
Azure AD (Entra ID) App Registration with Mail.Send application permission
Admin consent granted for the application
A shared mailbox or user mailbox to send from (no additional licence required for shared mailboxes)
Graph API vs Other Options for Branded Email
| Option C (your domain via our relay) | Option D (Microsoft 365 SMTP) | Graph API (Recommended) |
Authentication | You maintain SPF/DKIM DNS records | You maintain Microsoft 365 SMTP AUTH and DNS | Automatic — your Microsoft 365 tenant handles it |
Delivery Visibility | We see relay side only | No visibility for either party | Full — your Microsoft 365 admin centre |
Ongoing Maintenance | DNS record updates if our infra changes | Credentials, SMTP AUTH, MFA exclusions, DNS | None — set and forget |
Failure Mode | Silent if DNS is misconfigured | Silent at multiple stages | Errors reported back to MicrOpay |
Network Dependencies | Our relay must reach recipient | Port 587 to smtp.office365.com only | HTTPS only (port 443 — confirmed open) |
Requires Microsoft 365 | No | Yes | Yes |
Getting started
Contact your Account Manager or The Access Group support team to enable Graph API email integration for your MicrOpay environment. We will provide a step-by-step setup guide for your IT team. Most organisations complete the setup within a single change window.
Frequently asked questions
Why are my email pay advice not being received?
The most common cause is a custom From address that fails email authentication. If your From address uses your own domain but the required DNS records are not correctly configured, receiving servers will silently discard the email. If you are experiencing delivery issues, support will recommend switching to the standard configuration (Option A) as the first step to restore email delivery.
Can I use my company’s email address as the From address?
Yes. The recommended approach is Microsoft Graph API integration, which sends email directly through your own Microsoft 365 tenant with full authentication and delivery visibility. If you don’t have Microsoft 365, Option C allows you to use your domain via our relay with DNS changes. Option B gives you a unique sender identity without any DNS configuration.
Will recipients see the Reply-To address when they receive the email?
Most email clients display the From address in the inbox view, but when a recipient clicks Reply, the response is addressed to the Reply-To address. This means replies go to your team even though the From address shows our domain.
What happens if I configure my own SMTP server and it goes down?
Only Option D supports connections to Microsoft 365 (smtp.office365.com on port 587). Non-Microsoft SMTP servers cannot be reached from the hosted environment. If your Microsoft 365 SMTP connection fails — due to credential expiry, SMTP AUTH being disabled, or MFA enforcement — MicrOpay will fail silently with no error displayed. If you report email issues while using Option D, support will recommend switching to the standard configuration to confirm MicrOpay is generating emails correctly.
Do you monitor email deliverability?
Yes. For Options A, B, and the relay side of Option C, our infrastructure team monitors sending IP reputation, blocklist status, and authentication pass rates. For Option D (your own SMTP server), we have no visibility and cannot monitor delivery.
I’m using a @gmail.com or @hotmail.com From address and emails aren’t arriving.
This is expected. Google and Microsoft publish strict DMARC policies (p=reject) that instruct all receiving servers to reject emails from unauthorised sources. Our relay is not authorised to send as gmail.com or hotmail.com. These domains cannot be used as From addresses regardless of your configuration. Change your From address to Option A or B to restore delivery.
What will support do if my non-standard email configuration isn’t working?
Support will always recommend reverting to the standard configuration (Option A) as the first troubleshooting step. This confirms that MicrOpay is generating and sending emails correctly through our authenticated relay. Once delivery is confirmed working on standard settings, we can work with you to re-establish your preferred configuration or explore Graph API as an alternative that avoids the common pitfalls of Options C and D.
How do I request a change to my email configuration?
Contact The Access Group support team with your preferred option and the relevant details. For Option B, provide your preferred client identifier. For Option C, our team will provide the DNS records you need to add. For Option D, provide your Microsoft 365 SMTP credentials (only Microsoft 365 SMTP is supported). For Graph API, let us know you’d like to enable it and we’ll provide the setup guide for your IT team.