Report an existing service issue with the details needed to investigate it, or use the contact page for a new service question.
SAFI.pk support is the starting point for questions about an active service or account. Identify the affected domain or product, describe what happened and include a non-sensitive error example. The applicable service terms define support coverage.
Choose the ticket route when the request needs attachments, account history or ongoing follow-up. Use other listed channels for the enquiries they support, and keep passwords and security codes out of general messages.
Use the channel appropriate to the request and the coverage on your service.
Keep the issue, attachments and follow-up in one ticket so the history stays together.
Open TicketEmail your question with the affected service and a short description of the issue. Response coverage follows the terms of your service.
Send EmailBrowse published guidance for the issue before changing a live configuration.
Browse ArticlesSelect the topic closest to the affected service so the request has useful context.
Include the name and the registration, renewal or DNS change you need help with.
Identify the hosting account, failing application and any recent environment change.
Describe the affected address, delivery symptom and mail provider without sharing passwords.
Provide the affected URL and certificate or security symptom through the appropriate private support route.
Invoice identification, payment queries, changes to a plan and renewal or cancellation requests.
Send the WordPress error and recent plugin or theme changes for troubleshooting review.
Service
Affected product
Error
Exact symptom
Changes
Recent configuration
History
Ticket reference
A useful support request lets the investigator identify the service, reproduce the symptom and understand recent changes. Include those details first; work beyond the existing service may need a separate scope.
Check the evidence before changing settings. Keep a record of the current configuration so you can reverse an unsuccessful change.
For an unexpected destination, check the domain's authoritative DNS and the record involved. Compare it with the intended host and consider resolver caching. Avoid repeatedly editing records while an earlier change is still being cached.
For a certificate warning, record the hostname and exact browser error. Check certificate coverage and expiry before changing redirects. Mixed-content warnings also require checking the page's asset URLs.
For a delivery problem, retain the bounce message and sending domain. Check the provider's required authentication records and whether the message passes alignment. Do not change a restrictive mail policy without understanding its effect on legitimate senders.
For a slow site, identify a reproducible page and compare server errors, resource usage and recent application changes. Test one improvement at a time; a larger plan will not by itself repair every application bottleneck.
Questions about reporting and following up on a service issue.
